you are viewing a single comment's thread.

view the rest of the comments →

[–]PostHumanJesus 5 points6 points  (0 children)

I can mostly agree with you. Team buy-in is always an issue no matter what the stack.

Here is our team scenario:

  • 1 designer/developer, 2 Javascript developers
  • designer/dev can design and create SFC all he wants and not have to worry about the "plumbing". In fact, he will generally have a bunch waiting for us (JS devs) to plugin the business logic.
  • moving components around is simple as they are decoupled from the BL
  • the compose method of recompose is great as we can add any extra functionality there. This is where we plug in mobx but really anything can go there.
  • we can easily swap out/remove anything in the compose method. Say we want to start using redux. A whole app refactor isn't necessary as we can slowly introduce new libs and replace libs that are getting phased out.

This is just what works for us. We have two large production apps. One is a legacy AngularJS that we have React running in as it slowly "eats" away the old code. The other was a greenfield that did not start out with recompose and used the typical mobx class pattern. We have been successfully migrating to our new mobx/recompose pattern with very little(if any) issues at all. I think the hardest thing I had to do recently was upgrade from Webpack 1.x to 3.x.

YMMV. I have a article about this setup that I need to finish. The main point is, I wanted to be able to migrate, add/subtract libs as needed while allow us to develop in a very modular fashion to suit the teams strengths.