3 ms·
As you say, some tradeoffs are free, others aren't. One mistake I made is introducing a complex state management solution early on (NGRX); it had many benefits
by dSebastien 6y ago
As you say, some tradeoffs are free, others aren't.
One mistake I made is introducing a complex state management solution early on (NGRX); it had many benefits for code quality and overall FE architecture, but it also introduced additional layers, which required more code here and there for all details.
Entities that we get back are stored separately, then put together through selectors when they're needed on a screen. And all that jazz does take time & energy.
The net result is data consistency across components/screens (which is great), separation of concerns and clean code (cool), but at the code of slower development.
Even though, as I'm writing this, I also think about the alternative. Not having it means having less structure, maybe more issues to fix everywhere due to the lack of consistency, etc. It's not a choice that I can weigh easily, even now. I knew the tech already, used it in production before, and it still wasn't easy after all. Details details ^^
- burnthrow 6y agoFirst, great blog post. > The net result is data consistency across components/screens (which is great) You probably don't need to be told this, but... how badly was the data really going to drift during a session? If a user notices that part of the UI is stale, they just hit reload, not a big deal. This could be improved later.
- dSebastien 6y agoYep, good point. I do see it now. I absolutely didn't back when I started working on that. I had just delivered & supported an enterprise front-end framework (https://stark.nbb.be/ https://stark.nbb.be/) for which we HAD to help fix issues with state management. But of course, I just looked at it from the wrong point of view... The point of view of a technical guy, and not the one of a founder. I'm learning.. ;-)