I clicked on this, hoping to find something I could share with my team. Sadly, about the only one of these you got (sort of) right is SRP.

Let's go through the rest of this list and look at how we could make it more share-worthy.

Open/Closed principle. This is literally talking about extending base classes. If you look at React itself, you don't go in and change the definition of PureComponent because you want a different component. Instead, you extend it with new behaviors. It's better if you use composition than not, but whether you use it or don't does not affect whether you're implementing Open/Closed.

Liskov Substitution. Typescript has nothing to do with this. Again, let's look at React itself. If you provide anything that's a subtype of Component, React knows how to draw it, regardless of what you put in it (unless your component throws errors of course). You can of course use Typescript to aid you in Liskov substitution in some instances, but IME most developers don't use it that way.

Interface Segregation. This is one that makes most sense if you're using Typescript. An example might be that you have an IFormState interface that has isDirty and hasErrors and you combine that with an IUserState that has FirstName, LastName, Address, etc., and then you can hand the data object that implements both interfaces to something that needs an IFormState or an IUserState (and this kind of circles back to Liskov Substitution above), and Dependency Inversion below.

Dependency Inversion means you don't even reference a concrete implementation in your component. Your example is still not an example of this because you are still directly referencing the implementation, even if it's your own implementation. I'd argue that ES6 makes it really difficult to truly practice DI, because it encourages you to reach out your hand for specific implementations and it drops them right in there without apparent cost. A true example of DI would be for example if you're using Redux and your mapDispatchToProps maps an action creator to a prop that comes into your component. And all you know is what arguments it takes.

It takes a lot of courage to go out and put your ideas about good practice out there, because it's going to attract comments like this. I'm responding, not to be nasty, but because I know that Medium articles tend to be shared far and wide and I think it's important that if someone is going to take the trouble to read an article like this they have an opportunity to understand the concept. Best wishes.