I'm a Redux maintainer. I'm really excited about the changes in this release. They're primarily internal, but it should help React-Redux work a lot better with React's changes down the road.
In case anyone's wondering, this _should_ be a drop-in release for most users. Just bump your package version and update. If you do run into any problems, please file an issue!
I recently wrote a blog post that goes into more details on how the implementation has evolved over time, and why we changed several aspects of behavior for this release:
If anyone's got questions, ask away!
The big blocker for us shipping a `useRedux()` hook is that there's currently no way for a function component to bail out of re-rendering once it starts, and calling `useContext()` subscribes that function component to _any_ update of the context value. The React team has an issue tracking that (https://github.com/facebook/react/issues/14110 ), and as far as I know that's something they intend to include before 16.7 goes final.
Once that's available, we can look at implementing an official `useRedux()` hook, and ship it in a future release.
That same release would likely also rewrite the guts of `connect` to actually use hooks internally as well. I already threw together a proof-of-concept PR that does this (https://github.com/reduxjs/react-redux/pull/1065 ).
No specific timeline for that, largely because Suspense itself is still very much in development. The React team recently published a roadmap for features like Hooks and Suspense , and the data fetching aspects aren't expected until sometime next year. So, there's not a lot we can do on our end until there's a lot more clarity on how to actually work with this stuff in React itself.
Having said that, I don't immediately see anything that would prevent us from having a React Suspense cache that is backed by a Redux store. I've seen a couple people playing around with hacky prototypes that look intriguing.
There's some other concerns we'll need to figure out around React's upcoming "Concurrent" rendering capabilities as well. I wrote up some thoughts in a Reddit comment recently .
I have nothing against the package but is this the norm for package development these days to treat people like testers?
They're saying, "we've tested this to work without any code changes, but since we're not Gods there might be some edge case we missed. In that case, please let us know so we can fix it for you and everyone else who might have the same issue."
We published beta releases and asked for feedback . I honestly would really have liked more actual responses, but at this point we have no indication that there are any issues beyond what's expected from the known published breaking changes. At some point, you just gotta ship it :)
In the real world, people always use software in ways that you didn't anticipate. I'm pretty confident in the quality of this release, but I'm also realistic and know that it's quite possible there's some edge case that we weren't aware of. So, I'm just saying that if anyone sees issues, we'd like to know about them.
We've already completely revamped the React-Redux docs . They're now published as a separate site, and we're writing all-new content, like guides on how to best use `connect`. There's plenty more topics we plan to cover, but it's a big improvement already.
Meanwhile, we're also working on a new build setup for the Redux core docs. Once that's ready, we'll turn our attention to actually revamping the actual Redux docs content and structure. (There's an existing issue if you'd like some info on some of the plans ).
So, with that in mind, I'd specifically like to ask:
- What do you think are the biggest strengths and weakness of the current Redux docs at https://redux.js.org ?
- What topics do we do well?
- What is not covered, or explained poorly?
- What would be the biggest improvements we can make to the docs structure and content?
I'd appreciate any constructive feedback people can offer.
Finally, we've got a new `redux-starter-kit` package  that can help simplify common use cases like store setup, writing reducers, immutable update logic, and even creating "slices" of your store automatically. I'd encourage people to try it out. I talked some about this package in my recent ReactBoston talk on "The State of Redux" . We'll be emphasizing this package when we rework the tutorials and other parts of the docs in the near future.
The React-Redux typings are separate, in Definitely Typed. We're considering moving the Redux typings over there as well.
I like types (I've use both Flow and Typescript) in general, but I can also admit that they can cause more type specific coding that is unrelated to the actual problem that I want to solve. It's somewhat of a rabbit hole though, it is hard to go back once you've started. It would therefore be great if there was something more than the test cases provided at flow-typed when trying to to learn redux typing.
Also, Dave Ceddia wrote a good post comparing Redux and the context API:
FWIW, my rough stats indicate that somewhere around half of all React apps use Redux, and Redux is also used with other UI frameworks as well. Redux definitely isn't going away any time soon :)
That is because context was never intended as a replacement for Redux or any other state management library. In fact Redux itself uses context under the hood.
Context is more of a low level api. Somewhat similar to TCP/IP. You never work with TCP/IP directly but use high level abstractions like HTTP that work on top of TCP/IP and provide a simple interface.
Personally, I find for mid-large apps that Redux is usually a better approach. For small-mid, you're likely better off using the new context directly. Also don't forget you can maintain in-component state.
React Context makes a lot of sense though, because you'll effectively be able to create your own Redux nested at any level in the DOM. This means local state will be much easier to manage and you won't have the issue of having to stuff all your disparate contextual data into one shared store.
While with Redux, not that I am bitching about it, it first states that I need to accept several principles before I can better appreciate it. Then here comes all the middlewares, like redux-saga/redux-thunk and the list goes on. As a causal, meaning I am not writing js fulltime but do use it in some non-trivial situtation when needed, I feel it quite heavy and burdensome, making hesitant to adopt it unless being asked to.
Lots of people throw around the word "boilerplate", but everyone seems to mean something different by it . Can you clarify what _specific_ things you mean by that?
One area that I always felt "there has to be a better way" was defining action names. Typing the same thing twice, as insignificant as it is in the grand scheme. I saw a few libraries that had answers for this, but none were "standard."
Well outside the scope, but it would be nice to easily use action names as navigators via an editor extension. Rekit is doing some really interesting work to use Redux as the way to access an application.
I am assuming that this should be faster since it uses react's "proper" API?
Unfortunately, while I'd also hoped that v6 would be faster for the same reasons, it's a lot more complicated than that. I wrote about the performance implications of the changes specifically in my "implementation" blog post .
If you do see performance issues with v6 in your own production apps, please file an issue and let us know.