4 ms·
The issue with Redux is that a dispatch() and hence a state update causes a synchronous (hence blocking) update of the view. Andrew Clark better explains the d
by sktrdie 7y ago
The issue with Redux is that a dispatch() and hence a state update causes a synchronous (hence blocking) update of the view.
Andrew Clark better explains the difference in this tweet: https://twitter.com/acdlite/status/1195453776217296896 https://twitter.com/acdlite/status/1195453776217296896
> Redux architecture depends on the ability to block the main thread until rendering is complete. Once you make rendering non-blocking, your store is no longer synchronized with the UI. Leading to data races and inconsistencies.
Many view layers are moving towards non-blocking rendering as they need to account for things such as different priorities based on what the user needs: for instance a user typing needs larger priority than a banner showing.
Once it is non-blocking it's hard to keep a store and several UIs elements in sync. For instance your store might say isLoading:true but the UI might not show that since it's rendering/working another higher-priority element on the screen. And then you might have another view that depends on the isLoading:true which causes another thing to appear on the screen before the other element is shown... all this leads to inconsistencies and race conditions.
Essentially the problem is that we have lots of code that does (especially in thunks):
store.dispatch(FOO)
const state = store.getState()
// here we expect state to contain changes done by FOO
// but with non-blocking UI this is no longer the case
- acemarke 7y agoAndrew's not wrong, but I'm also not entirely convinced it's as big of a concern as he's describing. For context, Andrew is a co-creator of Redux, and is a current React core team member. He's spent the last couple years working deeply on the "React Fiber" rewrite that became 16.0, and the "Suspense" and "Concurrent Mode" features that are now available in alpha. He's definitely right that Redux's synchronous update model is somewhat limited compared to how React's "Concurrent Mode" needs to be able to dynamically re-order state updates based on priorities. But, it remains to be seen how much of an actual problem this is in practice. Andrew's been heads-down in this feature for a long time, and so it's natural that he's seeing everything through that kind of a lens. We've got an open issue to discuss and analyze how React-Redux might be able to work better with CM and Suspense: https://github.com/reduxjs/react-redux/issues/1351 https://github.com/reduxjs/react-redux/issues/1351
- the_gipsy 7y agoIsn't the issue here that a view is causing something, instead of the store? If a view would just render and dispatch messages on user events, then this wouldn't really be an issue, as far as I understand. The store and "runtime" can take care of loading stuff, independently of being rendered asynchronously, or not.