4 ms·

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 fin

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`

rtpg 10y ago
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.
- mathw 10y ago
  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!
  - galephico 10y ago
    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?
    - mathw 10y ago
      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.
    - rbalicki 10y ago
      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.
      - zinckiwi 10y ago
        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.
    - seanwilson 10y ago
      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.
      - mathw 10y ago
        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.
gm-conspiracy 10y ago
Is #1 considered this? https://en.wikipedia.org/wiki/Proxy_pattern https://en.wikipedia.org/wiki/Proxy_pattern
- fphilipe 10y ago
  I'd say that's a Façade: https://en.wikipedia.org/wiki/Facade_pattern https://en.wikipedia.org/wiki/Facade_pattern
  - vog 10y ago
    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.
JustSomeNobody 10y ago
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?
- ng12 10y ago
  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).
- ponyous 10y ago
  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.
  - JustSomeNobody 10y ago
    I feel you took my comment too personal. Is wasn't an insult to anyone.
gurgus 10y ago
Awesome response - are you able to give me an example of what you mean "wrap third party components"? Thanks :)
- dragonorta 10y ago
  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.

rtpg 10y ago

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.

mathw 10y ago
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!
- galephico 10y ago
  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?
  - mathw 10y ago
    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.
  - rbalicki 10y ago
    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.
    - zinckiwi 10y ago
      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.
  - seanwilson 10y ago
    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.
    - mathw 10y ago
      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.

gm-conspiracy 10y ago

Is #1 considered this? https://en.wikipedia.org/wiki/Proxy_pattern https://en.wikipedia.org/wiki/Proxy_pattern

fphilipe 10y ago
I'd say that's a Façade: https://en.wikipedia.org/wiki/Facade_pattern https://en.wikipedia.org/wiki/Facade_pattern
- vog 10y ago
  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.

JustSomeNobody 10y ago

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?

ng12 10y ago
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).
ponyous 10y ago
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.
- JustSomeNobody 10y ago
  I feel you took my comment too personal. Is wasn't an insult to anyone.

gurgus 10y ago

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

dragonorta 10y ago
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.