4 ms·
You haven't done any front end development recently I imagine? The entire purpose of what people do with state management and contexts is to decouple this.
by unconed 4y ago
You haven't done any front end development recently I imagine?
The entire purpose of what people do with state management and contexts is to decouple this.
- feoren 4y ago> You haven't done any front end development recently I imagine? Yes, I do front-end development every day. No, I have not done any React/Angular/Vue development recently. The tunnel-vision idea that "front-end development" must mean using one of the Big Frameworks is exactly the idea I'm pushing back against. I tried them for a while (Angular and Knockout), but wrote them off because they couple the logical organization of your app to the DOM tree and they've never taken any steps to improve that (nor even accept that it's a problem). If you're talking about Redux, there are good ideas there, but it's really just trading one kind of global state for another.
- feoren 4y ago> The entire purpose of what people do with state management and contexts is to decouple this. I think I now understand what you're saying. You're saying people spend lots and lots of time trying to work around this exact problem, which is introduced by Angular, React, Vue, et al. Realize that this is entirely an extrinsic problem introduced by "component-based" architecture and that a different approach (HTML as one output of the program) avoids this entirely. Managing state is still hard (as it always is), but there's nothing that needs to be decoupled in the first place. It's similar to how "design patterns" are really workarounds for the limitations of OO programming: Redux is a workaround for the limitations of React.