Remove React-specific code in favor of gaearon/redux-react #249
Conversation
|
If you use NPM though, the split will be as easy as depending on two packages instead of one, and replacing |
|
Also.. should that be redux-react or react-redux? I think I'm in favor of react-redux now, that's more natural for React ecosystem. |
|
Hey, but this is the Redux ecosystem :D |
|
Haha. I think Babel does the right thing: https://github.com/babel |
|
I don't know if that's quite the same. Babel is a build tool, whereas Redux is a library. I prefer redux-react but I'm having trouble articulating why... Is this to be a Redux library for React users, or a React library for Redux users? |
|
@gaearon do you plan to have just those bindings in the |
|
Global name needs to look non-awkward. |
|
In English, we generally put the adjective before the noun, and I think that in this case, It's a tight match, but I think I'm voting |
|
If we're going to read it like an English phrase, then I think this a library for Redux users who also happen to use React, not React users who happen to use Redux. The difference between other projects like react-router is that React Router doesn't exist outside of the React ecosystem, whereas Redux could have redux-ember, redux-cycle, etc. But I totally see the other argument. Meh. I don't care, I guess. |
That's the project maintainer speaking in you. For now, I expect the majority of users is likely to feel they're React users trying Redux, not the opposite. :-) |
|
We can always change later. For now I feel confident that's what'll cause least confusion. |
|
Good arguments, @acdlite. :-) "Well, we've got all our state in redux, but we want to switch rendering engines." LOL. |
It kinda feels awkward yes :)
👍
Agree. |
Not much sillier than the inverse :) |
|
Will the idea be to one day merge back into one? |
|
Sounds like not, @mattapperson. The point is to abstract out the state-managing bits that are UI-agnostic. @acdlite, touché. :-) |
|
I'd rather not. It's easier to evolve them separately, and in fact I'm sure somebody's going to come up with better API for the React part. This also signals that Redux is welcoming to Ember, Angular communities. We want everybody to have a great experience, not just our React friends. |
|
I look forward to being able to introduce redux into my PrototypeJS app that I still manage. 😭 🔫 |
|
@gaearon that makes sense. Thanks for the clarification! |
|
For whatever its worth, huge plus 1 from me for splitting it up. Loving the patterns in redux (and its small filesize), but would love to be able to try using it with other renderers too as the number of options keep growing: https://twitter.com/HenrikJoreteg/status/619543358151634944 |
|
I vote for |
|
👍 for |
|
The opinions are split: https://twitter.com/dan_abramov/status/619976807995932673 |
Remove React-specific code in favor of gaearon/redux-react
Per #230, the plan for 1.0 is to split Redux into two (I promise, just two!) packages:
We'll have different UMD builds for each. It's slightly more pain for the common case, but I think it's justified because React bindings API needs more experimentation than the core API, and we don't want to bump core versions too fast, as all ecosystem (middleware, devtools, etc) will depend on it.