Hacker News Reader

Comment by armandososa | Hacker News Reader

OK. Here's what I've learn after ~2 years of doing react myself.

1. Wrap third party components, so you can swap them easily if they become unstable or you find something better. 2. If you have a codebase that predates create-react-app, take a look into its configuration, webpack is a complex beast and they've figured many optimizations. 3. Learn the concept of High Order Components and use them to abstract common functionality (for example, retrieving data from an API) 4. Even if you use Redux (I do and I love it), not everything belongs in there, use local state whenever it makes sense first. 5. Never, ever, depend on anything inside `react/lib`

View on HN

The more I've thought about this the more I think the first point is the best decision for every long-lived application.

Wrap _all_ third party library calls. This lets you reduce the scope of these calls to "approved" ways and make much stronger assertions about who's doing what in your code.

This gets super useful the further down the line you get to adding really complex features. Being able to isolate all the places where certain objects get created to add a permission check is nice.

It also makes testing easier because you have some nice entry points to mock.

Raw usage of things like an ORM can let you get through a prototype super quickly, but makes editing the application later on quite hard.

Yes. Definitely. I have benefited enormously from doing this in C# for a few years now. Certainly the wins in testability can be significant, but it also isolates the third-party dependency's behaviour and lets you wrap it with something that exposes the interface you actually wanted. Which you can test in isolation and be confident in.

It's a shame it's really really tedious though!

Sincere question: do you really have the feeling the over cost is worth it? Do you do this for EVERY external library you're using?

It really depends on the library. Sometimes you look at the API of a library and you just want to wrap it because you know you're going to have to do a lot of work to get the data in and out of it in the right shape, or the lifecycle management is a pain, or the types involved aren't going to play well with tests, or it's just fundamentally relying on external state, thus preventing me writing proper unit tests of anything which might call it.

Other times, no, it doesn't seem worth it. And I don't do it for every single external library I use.

Although it does tend to end up being most of them - which seems to be a consequence of the way I've generally done n-tier application design at work. I'm not always a fan of this architecture, but sometimes it does fall out nicely.

No, some libraries (like React-bootstrap) export a bunch of components that don't really need a facade. But be careful. Later, when you need to modify functionality (and it can't be done via modifying the bootstrap variables via Less) it's a slight pain to retrofit.

Even so, I like to keep the imports local so I only have to change one reference to a custom-wrapped version if/when the need arises. I have a lib file to act as a manifest of components, and while most are mine, there are also some "export {Grid} from 'react-bootstrap'" type things in there.

Yeah, I don't get it. Swapping out a third party library is rare and usually because you want to get extra features another library doesn't have or some other big reason. Given how rare it is I would just use the library as is and refactor if/when the time comes. If you wrapped every library you'd waste a lot of time.

I had a senior developer suggest I wrap jQuery one time.

Honestly in JavaScript there's very little call for it because the language is so flexible, and you can't really build anything that's unmockable.

C# is a very, very different matter, and that's the perspective I was initially commenting from.

Re: #1, this is something non-web devs learned a long time ago. I wonder why there's not more sharing of this type of best practice information. Everyone stays in their own bubble, maybe?

It was a lot more difficult in the jQuery days. Requiring a script often did non-obvious things (global variables, touching the DOM, registering even listeners, etc).

Even web devs learned this a long time ago. And no we are not staying in our own bubble. As you probably know web is huge and it's hard to know all best practices. Even in the language you are programming there are probably things you don't know. People learn all the time, people start learning all the time.

It feels like people have superiority complex over front-end devs and lately specifically javascript. It bothers me. What if you tell me your language of choice and every time I see it mentioned somewhere I will post some random "intellectual question" combined with stereotype that will make you feel stupid and just demotivate you a bit. Maybe I am missing something but your comment made me feel that way.

To answer your question fully; In my opinion it's because there is no single entity that owns the web. No one controls which things should be deprecated or continued, that's why it's happening much slower because big guys have to come to an agreement. Apple provides best practices for iOS, Google for Android,... MDN is a good resource but there is no official "BEST WEB PRACTICES" entity.

I feel you took my comment too personal. Is wasn't an insult to anyone.

Is #1 considered this?

https://en.wikipedia.org/wiki/Proxy_pattern

I'd say that's a Façade: https://en.wikipedia.org/wiki/Facade_pattern

No, Proxy fits better. To be a Facade, it would have to be implemented inside React to hide React internals.

Although many patterns boil down to wrappers around objects (Delegator, Proxy, Adapter, Facade, etc.), but that doesn't make them all the same, even though their UML diagrams may look almost the same. The difference is: On which side is the wrapper? Which interfaces does it provide? Which interfaces does it use? Those details depend heavily on which architectural problem you want so solve (and it should be one you actually have). The pattern then guides you through how exactly that wrapper should look like in that particular case.

Awesome response - are you able to give me an example of what you mean "wrap third party components"?

Thanks :)

I've done this in a project recently when I was trying out different third party autocomplete components.

I had my own autocomplete component that I would use wherever I needed an autocomplete, and that component would render the third party autocomplete and supply it with the props it required. When I needed to switch out which third party component I was using, I only had to change code in one place, instead of changing it everywhere I was using autocomplete.

Reply on news.ycombinator.com