Proposal: split redux-react into a separate package

[gaearon]

I'm not a fan of over-splitting.

However we already export React-specific parts separately (redux/react and redux/react-native). React also embraces some splitting in React 0.14 (react and react-dom). It's becoming harder to buy the argument that people mind splitting so much.

I've heard complaints that people don't understand what is “core” to Redux and what is not because of Provider and Connector baked into Redux. I've also heard people want to use Redux with Ember, Angular 2 and Deku. There is a work in progress on an Angular 2 example project.

Things like Provider and Connector are React-specific and there also may be better ways to write them. It's harder to focus on developing them (and maybe bringing in additional functionality) when they're right inside the core. At this point there's so little API that binds them together (basically { getState, dispatch, subscribe } is their only common point) that I think splitting might bring more benefits than inertia and/or management overhead.

Here's my proposal:

• Move Redux to reduxjs org
• Create “blessed” redux-react and redux-react-native
• When React 0.14 is released, we'll be able to drop redux-react-native altogether

We'll also see if there is interest in “blessed” Angular/Ember bindings, and people willing to maintain them.

Thoughts?

[gaearon]

One thing I want to be able to do is to make breaking changes to redux-react without affecting the core.

[gaearon]

It's worth noting it's possible to do it the other way: move core to redux-core and have redux be a Swiss knife project. But I'm not sure it's right to give React preference given that people are starting to use it outside React (and indeed it's something I want to encourage).

[acdlite]

👍 (to the first suggestion)

[acdlite]

Perhaps it's just personal preference, but I'm more often annoyed by too much coupling versus too much splitting, and would prefer to err on the modular side.

[nkt]

This not makes sense for me because it makes harder to maintain projects written using redux. At least we'll have to track versions for both packages, instead of one.
Maybe this will be the correct step if the redux will contains helpers for other frameworks.
P.S. I'm already updating four babel packages every time it's updating.

[acdlite]

@nkt It's only two packages :)

[acdlite]

I've never understood that complaint about Babel. The version numbers for babel-core and babel are the same, and it takes like 2 seconds to update package.json.

[jprichardson]

Perhaps it's just personal preference, but I'm more often annoyed by too much coupling versus too much splitting, and would prefer to err on the modular side.

I could not have said it better myself.

Move Redux to reduxjs org
Create “blessed” redux-react and redux-react-native
When React 0.14 is released, we'll be able to drop redux-react-native altogether

I like this proposal 👍

[mindjuice]

At the moment I only plan to use Redux with React, but splitting out React-specific code sounds like the right architectural thing to do.

[gyzerok]

@gaearon I suggest you to wait a little. If after all maintaining single package become real pain you can split it.
For now I'd like you to be focused on 1.0 stable and not on doing unnecessary things at the moment :)

[tsingson]

@gyzerok, agree your call.

[clearjs]

IMO doing this move as part of 1.0 stable makes sense. This is kind of a breaking change, so the timing seems to be just right.

[gaearon]

If after all maintaining single package become real pain you can split it.

But this will be a breaking change in itself which will force us to jump to 2.0.
Sounds like doing it before 1.0 is more sensible if we're going to do it anyway.

(And we are: these libraries have very little in common.)