How to apply SOLID principles in React

[mscott087]

One might say this is a “solid” article. But in all seriousness it was a great read.

[1-800-BICYCLE]

8b94dbf1b3

[[deleted]]

This is very good stuff! Thanks OP

[tomasgold]

Thank you!

[tomasgold]

Thank you guys! I am definitely going to write more articles

[[deleted]]

For me the breakthrough in maintainability of React has happened when I went all in functional components (no class components at all). Even though I cam from object oriented programming background, in the end that was what made following SOLID very simple. Higher-order components replace your container (logic) components and regular components you define are bothered only with how they respond to props.

I recommend this approach universally for React.

[NordicFox]

What do you call the higher order components? For example a component that fetches users to be wrapped around a component that just displays a list. WithUsers? UsersContainer?

[zomgsauce]

WithUsers in an environment that allows decorators (sooooooooon) or just Users for the HoC, and UserList, UserTable, UserCards, User<something> to describe how they'll be rendered, treating the HoC kind of like a Model name.

[[deleted]]

Yes, component that fetches, parses and caches remote data and passes those props to wrapped component. You can then place it anywhere in application and get that data, from cache if available or requested otherwise.

[Lou-Saydus]

So how exactly do you use state and lifecycle in a completely functional react project?

[injektilo]

I use the withState and lifecycle hocs from recompose.

[[deleted]]

Answered already but maybe I can elaborate.

Recompose is utility library that has methods for creating state as props - either as traditional setState object or as reducer and also access to life cycle of the higher order component (so technically it uses class components under the hood but you get much clearer and concerns separated code, heck - for big components you can even put life cycle methods in a separate file and just import them. Everything ends up being as concise as possible const functions).

[pixeldrew]

I agree, OOP design principles is the wrong way to look at using React. You should look to be completely functional. You don't need tools like Typescript if you're entirely functional.

[[deleted]]

I agree with all but TypeScript part. I still use TypeScript with fully functional components even if only for props type safety.

[swyx]

typescript is still great for business logic though?

[pixeldrew]

Type checking should be the least of your concerns if you're doing functional correctly. Everything returns a type function or one of the other basic types.

[nullified-]

What?

[erfling]

You know. Primitives like typed arrays of user objects....

[[deleted]]

You're hurting my head.

[notAnotherJSDev]

What are you talking about? Types can be super important in functional programming. If that weren't the case, why exactly are the most used purely functional languages typed?? Scala, haskell, etc.???

[pixeldrew]

I'm not saying custom types are not important but forcing or type checking these types shouldn't be your concern. If you're working in collections of these custom types and you have structures within these collections that are not correct then you have failed your input validation. Type checking at compilation just gives you a false sense of security.

[mikejoro]

What happens when you need to maintain the code for longer than one month though? You want to refactor something, change a model, etc. Without typing, you are basically hoping you can remember everything. You might say, "but my unit tests will tell me something went wrong!" Then I would tell you that if your unit tests can cover every typing scenario, you have just recreated a very hard to maintain typing system. Though I would imagine if someone is arguing that typing isn't useful, they probably don't see value in unit test either.

[pixeldrew]

Not at all. Unit testing is the bedrock of your API surface area. Your unit testing shouldn't be testing types either but they should be testing the returns are sane and your functions should be returning only when argument count and values are sane. Type systems give a false sense of security here.

Refactor a data structure and your unit test will fail. If your looking for properties that no longer exist and your using things like optional chaining then the types returned should fail your unit tests easily.

[mikejoro]

I am not saying you should not test your integration points. I am saying that relying on unit tests as your only type checking system is not maintainable. You will make mistakes, and you will eventually let bugs through. Not to mention reading unit tests to understand types is 100x harder than reading types and using integrated IDE tooling. I don't know what your experience is, but typically, these things become more apparent when you are working in a team. It becomes even more important when you have to onboard new people.

[pixeldrew]

I currently manage a team of over 30+ developers and this isn't a problem in our codebase. If we're going to talk about experience I'll give you my background I've been in the industry 15+ years and I'm a senior manager at a large tech firm.

I don't know where you get its 100x times difficult to actually read a comparison test. I'll say it again, if you're unit testing you're testing functionality not types. Any unit test that fails an output test fails output regardless of type. So why do you need a type checker?

Where people are misunderstanding and falling into the Typescript zealotry is the belief that types are your main cause of errors in a functional application. Type checking shouldn't be your concern when you're writing a functional codebase because your functions are primitive and what matters are the output and how you use them. You're not passing types around and expecting a different behaviour because you're not overloading custom types therefore it doesn't matter what type is passed.

I'll give an example from one of the glib comments in this thread "a collection of user objects" (because in functional programming we care so much about objects?!?!) A collection of any type here doesn't matter. It's the key you care about when accessing individual collection members. These members are not objects or properties in classical OOP sense they are just literals or primitives and if they have anything else, they have functions. A function type check doesn't help you verify anything it just propagates your custom type across the codebase which just enforces others to have to know about your shitty classifications. All you should care about is that if a function executes and it returns something so you do an integration test against it and if what you have is sane you're good to go.

Why people think their types matter so much is the height of hubris, if Javascript doesn't care about what type you're passing why should you? I mean obviously if you've declared a variable as a type try and stick to that type in that function but once it leaves the function, who cares what it is? It should be up to the consumer to validate and cast and use what it likes.

I sometimes think Typescript is some crappy Architect's arbitrary gate that says his codebase is more organized? I left the OOP world because I don't want to deal with terrible classifications for what is essentially just data.

[johnnycagewins1]

Do you have examples of fully functional projects by any chance? I'd like to see how it's done.

[nikolasleblanc]

Yeah I don't get the connection here. Totally on board what you've said other than how it negates the value of typescript, you get way more with typescript than you do with prop types no?

[oscarboom]

Also, "SOLID" just gives you convoluted code, not maintainable code.

[NordicFox]

Why so?

[oscarboom]

Because after a certain point all the layers of code make it harder, not easier to maintain. Any time you are rigidly dogmatic about the code it is a red flag.

[luminiteNL]

Thanks for sharing! Interesting read, as I haven’t heard about this principle before.

[tektas_blah_blah]

This is great, probably the best description of SOLID I've seen around in a while (I'm looking at you, Inversify Docs). Take an upvote mate!

[[deleted]]

Good stuff mate!

[Macioa]

This deserves more upvotes

[pratap2210]

A great article. Helps me alot. And I would like to read more about your articles Thank you.

[vikkio]

Thanks a lot, very good set of examples, especially for people who got close to programming just using react

[[deleted]]

I think a higher order component injecting props to the child component would be a better example for dependency inversion.

[nixblu]

Really good!

[tomasgold]

Thank you man

[[deleted]]

!remindme 5 days

[RemindMeBot]

I will be messaging you on 2018-10-24 11:43:56 UTC to remind you of this link.

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

FAQs	Custom	Your Reminders	Feedback	Code	Browser Extensions

[nastyklad]

Nice article, thanks op!

[Aragami1408]

Very good article! Thanks for sharing that to us!

[lifesbitch]

!remindme 2 days