React Redux 6.0 released | Hacker News Reader

React Redux 6.0 released

github.com

84 pointsMBCook30 comments

Hah, beat me to posting this!

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:

https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

If anyone's got questions, ask away!

When will Redux have its cache ?

I assume you're talking about in relation to React's upcoming "Suspense" capabilities?

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 [0], 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 [1].

[0] https://reactjs.org/blog/2018/11/27/react-16-roadmap.html

[1] https://www.reddit.com/r/reactjs/comments/9xnvs2/how_does_co...

I'm curious about the direction react redux will take with the new hook api. What will the react redux hooks will look like? Will that be something that lands soon in an alpha?

Here's the issue for hooks: https://github.com/reduxjs/react-redux/issues/1063

Yeah, @tlrobinson linked our issue discussing it.

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 ).

> Just bump your package version and update. If you do run into any problems, please file an issue!

I have nothing against the package but is this the norm for package development these days to treat people like testers?

Wow, way to assume the worst out of something that's obviously well intentioned.

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 have an extensive unit test suite for React-Redux [0]. v6 passes that test suite, and the test suites for v5 and v6 are largely the same (minus tests that related to specific parts of the implementation, like the switch from old to new context).

We published beta releases and asked for feedback [1]. 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.

[0] https://github.com/reduxjs/react-redux/tree/9d50c2bd57642477...

[1] https://github.com/reduxjs/react-redux/issues/1083

Since it's a Redux-related thread, I'll toss out one other sub-thread to let people know what we're working on, and ask for feedback.

We've already completely revamped the React-Redux docs [0]. 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 [1]).

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 [2] 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" [3]. We'll be emphasizing this package when we rework the tutorials and other parts of the docs in the near future.

[0] https://react-redux.js.org

[1] https://github.com/reduxjs/redux/issues/2590

[2] https://github.com/reduxjs/redux-starter-kit

[3] https://blog.isquaredsoftware.com/2018/10/presentation-state...

Thanks for the great Redux docs. I was not able to find any solid information on how to use Redux with typescript in the docs. Since redux now comes with typescript types (I think), it would be nice to have documentation around how to use them and any best practices to follow and pitfalls to avoid.

We've got a work-in-progress PR on adding a docs page to discuss using TS with Redux: https://github.com/reduxjs/redux/pull/3201 . But, neither Tim nor I use TS ourselves (yet), so we're not experts and don't have the expertise to write this ourselves, or maintain the typings. That's gotta come from the community.

The React-Redux typings are separate, in Definitely Typed. We're considering moving the Redux typings over there as well.

I just encountered Flow type issues after the 85 release. I know the type defs are in flow-typed but it would be nice if you could also provide some guidance. There are just so many parameters for connect that it just blows my mind when I try to find the source error.

Unfortunately, that's not something we have any control over, or any real guidance on. Per my other comment in this thread, Tim and I don't use TS or Flow ourselves, and we haven't directly maintained the typedefs.

Have you considered asking the authors of the typedefs to contribute to that section? My guess they would be pretty honored to be able to help out directly with such a high profile package.

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.

Huh. My coworkers have been talking about React's context API as an alternative/replacement for Redux and that the industry is generally "moving away from using Redux." Is this at all true/valid? I've been skeptical since I like Redux a lot and haven't been able to understand how Context is a true replacement for Redux given what I have read.

I wrote a post earlier this year that talks about how things like context, GraphQL, etc, all relate to Redux. It's still relevant:

https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

Also, Dave Ceddia wrote a good post comparing Redux and the context API:

https://daveceddia.com/context-api-vs-redux/

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 :)

Vote for Mobx to replace Redux. Having done so, not missed a bit.

Agreed. State lifecycle is all the same but Mobx automates 2/3rds of the tedious work and is much more natural to use.

Not to mention that the API is very intuitive and programmer friendly. For me, using Mobx doesn't force me to write things its own way, but instead enables me to write things MY way, but just hook it up with Mobx when needed. It is a more of a library than a framework, a guest not a intruder.

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.

> I've been skeptical since I like Redux a lot and haven't been able to understand how Context is a true replacement for Redux given what I have read.

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.

kind of, yes: https://codesandbox.io/s/jznpj65nm5

You can effectively maintain your own component independent state via context and the context API. Where Redux shines is in predictable state management. Or more predictable depending on how you manage async requests to an external resource.

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.

once hooks are in, I think React Context will be a lot more usable. Right now, its composability isn't great because you have to use nested render props because it's not very HoC friendly.

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.

I used Redux in a major project, and really appreciated using a fairly standardized framework that translates between projects with support including Redux DevTools. However, all the boilerplate was a big drawback. There are scattered solutions, but adopting one takes away from the mainstream appeal of Redux. Is there any hope of a standard way to "reduce" some of the boilerplate?

Yes, absolutely! Per my other comment in this thread [0], please check out our `redux-starter-kit` package [1]. I'd appreciate any feedback on whether or not it helps you, and what other capabilities would be beneficial to include.

Lots of people throw around the word "boilerplate", but everyone seems to mean something different by it [2]. Can you clarify what _specific_ things you mean by that?

[0] https://news.ycombinator.com/item?id=18605421

[1] https://github.com/reduxjs/redux-starter-kit

[2] https://github.com/reduxjs/redux/issues/2295

redux-start-kit looks great. It's been over a year since I've bootstrapped a redux project, but I'd definitely use it next time.

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.

It would be nice to see benchmarks between the versions.

I am assuming that this should be faster since it uses react's "proper" API?

We did do a lot of benchmarking during the development of v6, and have a standalone benchmarks repo that you can clone yourself [0].

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 [1].

If you do see performance issues with v6 in your own production apps, please file an issue and let us know.

[0] https://github.com/reduxjs/react-redux-benchmarks

[1] https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

No.

Reply on news.ycombinator.com