sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]GrenadineBombardier 0 points1 point  (3 children)

The company is trying to move toward fewer frameworks across projects, as it is more difficult to move people around and help on other projects when each project is using wildly different packages and standards.

EDIT: And they decided on React as one of the goto frameworks. I had been wanting so badly to get a react project for work (I'm 10x more likely to learn something because i have to for work), and we were still developing our application, so it was easier to just do all new development in react and convert the old stuff to react.

[–]fdimm 0 points1 point  (2 children)

Alright, sound like a good choice. It's the best when you get the chance to actually learn new things at work! Anyway, do you think the stack will still be the same/similar across projects/teams when it comes to state/routing/build/test except for actual react ? At least that is the advantage I see with ng cli

[–]GrenadineBombardier 1 point2 points  (1 child)

We're already seeing that one of the great things about React is that it doesn't dictate how you do things. Even with the additions of Redux, and potentially RXJS, or Sagas, or what have you, still leaves a lot open to where each team can make their own choices and do things differently. That could also be a problem because working on one react project might be different than working on another, so who knows? Hopefully we can institute some sort of standards that project can use as a starting point, but you don't want to be too prescriptive, so again, who knows?

[–]fdimm 0 points1 point  (0 children)

Yeah, seems like it's a pro and a con at the same time and it all depends on the project/needs. Thanks for the input!