| I don't think React is the problem here. I think communication and leadership is where fault lies. 1. Why hire a team of non-webdevs to do webdev. (on 2nd read, it appears they wanted to use the same team from the WPF app... ¯\_(ツ)_/¯) 2. If you build and treat React components and their APIs as the abstraction layer, then they're just components... who cares how they're implemented. 3. Just because the existing project is big, doesn't mean your new one has to be... split it up! 4. Redux... the root "technical problem" My hot take is that the authors technical issues probably come from Redux and not React.
Using redux as the core of your application is like pouring glue on a lego set. In an ideal world this is great because everything is strong and well defined. In reality, it prevents flexibility and applies hard constraints to the entire system. That one choice of using redux effects the decisions you make in every component. You lose flexibility to encapsulate features and experiments. You're forced to bend over backwards to do things in specific ways. Redux is the JS equivalent of the Windows Registry. |
Love it.
I find Dan Abramov a great guy, but it was he who brought us Redux and rose to such fame because of it, and its now considered a bad way of doing things (or maybe just a ridiculously verbose api) and caused a huge amount of pain for a lot of people (I am not blaming him tho!)
Now we have hooks as a collaborative effort involving the same guy, but they feel hacky in a way, and almost like they will not last either.
It really feels like this reinvention for the sake of reinvention. I can easily imagine the API I would like for managing my data layer, but its seems like we are trying to shoe-horn something into the React way when maybe it isn't the right fit and we need something else.