Re:Ask HN: Go-to web stack today?
by interlocutor on Saturday January 05, 2019 @05:18AM
(#18830912)
There are simpler ways to do global state management than redux. The scenario you described is nothing new. Redux is new. How do you think people solved this problem before Redux? Does redux have a better way of solving this old problem? How would you solve this problem in an ASP.NET or JSP application that has server-side rendering? How would you solve it in an iOS app? My point is that this is a pedestrian, every-day problem that doesn't need a complicated solution. Redux is unnecessarily verbose and makes you jump through hoops without giving enough in return. Yeah, I know about time-travel state debugging, but YAGNI.
If this is true
> My point is that this is a pedestrian, every-day problem that doesn't need a complicated solution.
then you should be able to answer the question below, yes?
> How do you think people solved this problem before Redux?
Re:Ask HN: Go-to web stack today?
by wisecommentator on Saturday January 05, 2019 @09:04AM
(#18831674)
If the app is MVC-structured you can store global state in the application object. Here's a simple example:
https://github.com/edman3d/mvc-router/blob/master/DemoApp/Co...
Some frameworks provide session state and cache to store global state. No need for actions, reducers etc.
You can avoid flux longer by simply making a component which stores that shared state, passes it down via props to children, and along with some callback functions to update that state. It is almost exactly what is needed most times and it prevents a problem we’ve dug our selves into before which is making everything via the store because we didn’t want to pass so many props.
Re:Ask HN: Go-to web stack today?
by aloukissas on Saturday January 05, 2019 @01:29AM
(#18830327)
Even better: https://reactjs.org/docs/context.html
Why do so many people forget about context?
Because it was internal and undocumented for a while and was properly exposed as an API only a few releases ago.
I have a react native project that I resisted using flux (in my case, mobx) as long as possible to try this theory out. The situation I ran into that instantly told me I needed global state management was when I had an index screen for list of resources, and a edit screen for a single resource. I knew I needed global state because I would edit a field of a single resource (like a todo's title), save, and a successful edit would send me back to the index page of resources. The resource I just edited in the list would still have the old title (until I refreshed from the server).
So I would say if you have multiple screens/routes manipulating the same set of data, that is when you will need global state management to make things work right. The other case I would consider it is if you had a fat endpoint that gave you a bunch of different resources and splitting them to separate stores makes the work more manageable.
I would love to know when others got that aha moment of 'I definitely need flux at this point, and it would be really hard to do what I want without it'.