141–150 of 310 posts
Earlier quoted context omitted.
Shoutout to MobX-state-tree
It is a lot slower though, I had to migrate from it to normal mobx to come back to descent performance when having a few thousand objects.
Earlier quoted context omitted.
Agreed! I'm surprised at the comprehensive work going into researching the history of state management in this article while completely missing MobX. What problem does MobX not already solve?
What problem does MobX not already solve? I’d say the two biggest hazards with the reactive/declarative style are cyclic dependencies in the data model and remembering history. Tools like MobX let you write quite elegant code in the right circumstances but they are less helpful if, for example, you have a complicated set of constraints and the effects of changing one value in your state can propagate in different dir…
Earlier quoted context omitted.
It's not even necessarily the same information, but small pieces of one bigger piece that need to be updated once some of the other smaller pieces change
Yeah this. The classic is unread state in a mail app. Unread state is usually displayed both as bold state per message in a message list, and as a count in the folder list. These need to stay in sync as the user reads mail (and sometimes marks read state explicitly). Two views of the same underlying state.
Earlier quoted context omitted.
Mobx has made me finally appreciate frontend programming again. It's like people want to deal with the insanity that is redux only because it's a more pure functional style which react seems to promote.
Something I like to point out to teams when it's the case, and it's often the case, is "When is the last time anyone on the team has used time travel debugging? Never?".
I'll agree that the Redux DevTools "skip action" and "jump back to action" features are not all that commonly used in practice. I _maintain_ Redux, and I don't even use them that often.
On the other hand, the ability to see a written list of all dispatched action type names is valuable by itself. So is the ability to click one of the listed actions and see the action contents, state diff, and final state. _That_ is very powerful.
Beyond that... I now work at a company called Replay ( https://replay.io ), and we're building a true "time traveling debugger" for JS. Our app is meant to help simplify debugging scenarios by making it easy to record, reproduce and investigate your code.
The basic idea of Replay: Use our special browser to make a recording of your app, load the recording in our debugger, and you can pause at any point in the recording. In fact, you can add print statements to any line of code, and it will show you what it would have printed every time that line of code ran!
From there, you can jump to any of those print statement hits, and do typical step debugging and inspection of variables. So, it's the best of both worlds - you can use print statements and step debugging, together, at any point in time in the recording.
Additionally, because Replay records the browser's OS calls, it captures _everything_ that happens in the page. That means you can debug _any_ website or JS app, no matter what framework it uses - React, Vue, Angular, Svelte, jQuery, or vanilla JS.
I actually recently implemented a POC version of support for the Redux DevTools in our Replay debugging app, so that if you do record a Redux app (or Jotai, or Zustand, or NgRx), you can use that same Redux DevTools UI to see the action history.
So, yes, time travel debugging _is_ an amazingly powerful concept. It's just ironic that that particular aspect of Redux didn't end up getting used that much... but the Redux DevTools themselves are still valuable, and Replay is actually a far superior "time travel debugger" overall.
Earlier quoted context omitted.
Fun fact: one of the XState devs did a proof-of-concept showing how to use XState state machines as Redux reducers and integrate the side effects handling as a middleware: https://github.com/mattpocock/redux-xstate-poc We'd like to work together to turn that into a more official integration sometime soon.
This looks excellent. I see a lot of potential in the idea of combining the strengths of RTK(+Query) and XState. Thank you for sharing!
Earlier quoted context omitted.
Cache stays simple even for large applications. It never gets "sufficiently complex".
As the joke goes, there are two hard problems in software: 1. Naming things. 2. Cache invalidation. 3. Off-by-one errors. Caches are tricky beasts. First, you need to update them when the server-side state changes (for example, two people editing a single Google doc). Second, writing state changes to the server and waiting for confirmation is too slow for many kinds of interactions. In these cases, it's typical to op…
For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for me, which is handled very well by libraries built for that purpose. The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient. A lot of state can be local, and local state is easy to handle with…
Earlier quoted context omitted.
I think it's because redux is quite painful to use with very modern apps. Most of the time you need something like `redux-saga` or `redux-thunk` to deal with async side effects. I'm not sure which is the most popular today, but sagas are based on generators and trying to use those with typescript is very very painful and the underlying issue [1] is marked as a design limitation in TS itself. In addition, if you want…
You need redux saga because api interactions can be complex. I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display. But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy. Oh, an…
You can do all of that pretty easily with a vanilla redux.
Earlier quoted context omitted.
Something I like to point out to teams when it's the case, and it's often the case, is "When is the last time anyone on the team has used time travel debugging? Never?".
Depends on what you mean here specifically :) I'll agree that the Redux DevTools "skip action" and "jump back to action" features are not all that commonly used in practice. I _maintain_ Redux, and I don't even use them that often. On the other hand, the ability to see a written list of all dispatched action type names is valuable by itself. So is the ability to click one of the listed actions and see the action cont…
What I meant though, was that people get hung up on the some ideal of how Redux is and will work for them while the reality is often quite different.
For bigger projects, custom middleware is where the magic is. If you don't understand redux well enough to write your own middleware (it's not very complex, it's just under documented for some reason) then it's better to use one of the other, simpler abstractions instead of adding one abstraction (redux) then piling on more abstractions to make it usable.