31–40 of 48 posts
So, do very complex desktop applications use redux-like state management nowadays?
I ended up with a couple global queues (custom, async data pub/sub, similar to Rx) that each component could to subscribe to. A more reactive state management makes things a lot more simple. Only bare-minimum stateless children components (like buttons) are passed props with parent state.
Earlier quoted context omitted.
I don't recall my cs program actually dealing much with state management as a standalone concept. I feel like you could take this stance on almost any framework or library.
Probably because JavaScript as it is used in browsers and especially React is asynchronous and in CS you traditionally study classic programming languages which are mostly synchronous code, even if it is multi-threaded you still command where and how access to shared data happens most of the time. In JavaScript and React asynchronous aspect is mostly hidden from you hence need for things like Reudx.
Silly question: is state management used outside of the frontend world? The last time I developed desktop apps (it was a long time ago) no-one had ever felt the need to remove state from the individual components and add it to a global store. So, do very complex desktop applications use redux-like state management nowadays?
Silly question: is state management used outside of the frontend world? The last time I developed desktop apps (it was a long time ago) no-one had ever felt the need to remove state from the individual components and add it to a global store. So, do very complex desktop applications use redux-like state management nowadays?
Most applications store their state in sessions / memcached / redis / databases.
But, of course, some apps must have real time state management that is shared among thousands of users. Think high-traffic low-latency trading engines. Think multiplayer games.
If you want a really frictionless state management library for React, please try out my library https://github.com/baron816/use-structure It lets you make state updates using native JavaScript mutation APIs. It uses Proxies to convert those mutable updates to be immutable so that your component updates correctly. This will work: ... const arr = useStructure([]); ... arr.push(1, 2, 3) }>Add value But you could use dee…
Silly question: is state management used outside of the frontend world? The last time I developed desktop apps (it was a long time ago) no-one had ever felt the need to remove state from the individual components and add it to a global store. So, do very complex desktop applications use redux-like state management nowadays?
Applications that need to have state, surely have it. Most applications store their state in sessions / memcached / redis / databases. But, of course, some apps must have real time state management that is shared among thousands of users. Think high-traffic low-latency trading engines. Think multiplayer games.
You seem to believe that state is synonymous to "reactive store". Also, sessions/ memcached/ dbs have little to do with application state management.
Silly question: is state management used outside of the frontend world? The last time I developed desktop apps (it was a long time ago) no-one had ever felt the need to remove state from the individual components and add it to a global store. So, do very complex desktop applications use redux-like state management nowadays?
Lots of complex applications have always been using state machines, this is not a concept that originated from web front-end development. You can find them in Delphi, Visual Basic, QT, etc.
Did anyone use freezer.js before?
Earlier quoted context omitted.
> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.
This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application. Context and State are great, but they serve a different purpose than Redux.
My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will display, like user information, products list, project data, application settings, etc, a separable state machine should be used. This works well because components are responsible for their own state leaving the state manager clean from individual ui component information, and ui components are free to be passed whatever data improving reusability.