Future of redux-router: redux-simple-router?

[omnidan]

As you may have noticed, this project isn't actively maintained right now.

• @acdlite personally doesn't use redux-router anymore (correct me if I got that wrong 😅) and doesn't have time to maintain it.
• I comment and merge some smaller PRs when I get around it, but I'm really busy with other things too.
• @Scarysize has been helping out a lot lately and I'm really thankful, he has been keeping this project alive.

@jlongster developed a project called redux-simple-router - it is a lot smaller (and thus, easier to maintain) than redux-router. Some people already switched to that.

It seems like a better solution (redux-router re-implements a lot of features that history and react-router already do), so it probably makes sense to combine the projects (read: replace redux-router with redux-simple-router)

What do you think? Is there anything missing in redux-simple-router that redux-router has? Just let me know in a comment here.

PS: I haven't managed to get a hold of @acdlite yet, but once he gets online on discord I'll talk to him about it. (or he can just comment here 😄)

[Scarysize]

Also feel free to ping @omnidan or me (@Scarysize) in the redux-router Discord channel or pm us!

[jlongster]

Let me know whatever you all want to do. I don't think there's anything wrong with having 2 solutions, but whatever works. I can help with any transitions plans if needed.

[omnidan]

Unless we find enough people who can (together) actively maintain redux-router, it's going to be problematic. @Scarysize is doing good work, but there's so many issues with the current implementation. (He can probably explain this in further detail) I like how redux-simple-router is small, simple and easy to maintain.

If anyone has switched to redux-simple-router, would be nice to hear experiences, thoughts, etc. Would be really cool if we could get a "Switching to redux-simple-router" guide up.

[ellbee]

I just switched to using redux-simple-router in my current project at work and it has been seamless so far. It is a small project which doesn't ask a lot of the router, so I might not be hitting the cases where redux-router is the superior choice. As @jlongster says, it is 'ruthlessly simple'. I can understand everything it is doing, so I can be comfortable using it in a project even though it is less than a week old.

There is one thing that I know of that redux-simple-router does currently that redux-router does not, and that is work correctly with redux-devtools (I don't think that version of redux-simple-router is on NPM yet, but I imagine it will be soon)

[idolize]

Disclaimer: I haven't actually built anything with redux-router or redux-simple-router yet, but I've been trying to stay up to date on where it's going (I plan to overhaul my routing code soon to use react-router 1.0 and I'm looking to use one of these two solutions). So please forgive my ignorance if anything I write here is inaccurate.

From the docs, it sounds like redux-simple-router only stores a String of the current URL in the redux state. Personally, I'd much rather have the URL pre-parsed with Objects for params and query; I don't want to have to deal with string parsing.

Similarly, I want to be able to easily check if a given route is active or not based on the information stored in my reducer state. Redux-router has such a capability, and I'd prefer to avoid having to use anything too browser-specific to check this information, since it can really be expressed as a "pure" function of the state.

Anyway, in many ways I like idea of building something simple on top of react-router (because it makes maintaining the library much easier), but at the same time I also like the goals of redux-router to avoid having any real dependency on React (and just treating the route state as any other redux state).

It's a tough call, but at the end of the day I just want a simple way to keep my route state in sync with some convenient ways to update and check the status of that state. How pure, minimal, or decoupled the underlying implementation is doesn't matter much to me in any practical sense because I'm already using React, react-router, and redux anyway 😄

[acdlite]

redux-simple-router is a cool project. It's pretty similar to what Redux Router (then redux-react-router) was in its earliest version. It benefits from being less ambitious — Redux Router tries to store all the router state, including params, inside your Redux store.

There's an argument that Redux Router is overly ambitious given the current design of React Router. I've already done some work to help with this — the useRoutes module was designed largely for this library. But I don't have much time right now to contribute further to React Router so that Redux Router can be the best version of itself.

For now I'd say both libraries can continue to co-exist. I would like to give more attention to this library, but I just haven't found the time recently. Hopefully soon.

[acdlite]

Another reason I've neglected this project recently is that I haven't been using it heavily in the project I'm working on, which uses Relay. I wish I had infinite time for OSS, but it turns out I spend what time I have on projects that I'm actively using. Sorry :( I'll try to be a better OSS citizen going forward, and not start projects that I can't devote sufficient time to.

[gaearon]

Hey, please don't feel guilty for starting an open source project! We all appreciate the work you put into this, and open source projects don't always work out the way we want them to. (I'm screwing people over with not updating React Transform for so long too—like you, I don't find time to contribute in the past weeks because I'm busy with other stuff.)

If you don't think you can handle this project at the current stage, I think we'd all benefit from a little “state of affairs” summary, if you can find time to write it up. Basically: what your goals were, what makes them harder to achieve on RR side, tradeoffs of other approaches you saw in the wild, and recommendations you can give us with moving forward. If you don't have time to write it up, maybe we can chat for 30 minutes some day on the week and you can give me an idea verbally so I can write it up myself.

Most importantly, don't burn out. 👍

[idolize]

@gaearon @acdlite Agreed! Definitely not wasted work (just look at how your changes and thought process has shaped the 1.0 react-outer API). Plus, this project has put forth some great ideas about how to handle route state in redux. I'd definitely consider it a key part in the evolution of building redux/react applications.

I also agree that a "state of affairs" kind of post would be beneficial. Sometimes it's hard to know where and when to step in with a seemingly-stagnant OSS project, because frequently the author has thoughts and ideas that the general public just isn't aware of (as we both know, a lot of the best "programming" often times takes place inside one's head, away from the keyboard, while laying in bed or taking a shower 😄).

Even if it's just a "hey, I don't have the time or resources to work on this anymore" there is no need to feel bad - it just gives others an opportunity to step in where you left off!

[kmudrick]

FWIW, I had been struggling to get redux-router working in a universal app for the past 2 days, running into multiple issues (documenting issues, dependency issues, etc.) I saw this thread and gave redux-simple-router a go, and had it working in less than 2 hours.

[jlongster]

I agree about both library co-existing. I wasn't trying to take anything away from this project at all, and I'm sure there's some good things to be learned from it. I thought about contributing to it, but I wanted to try such a different approach that I didn't really see how without starting a new library. The main problem I have with this library is that it stores everything in redux, which makes it not serializable, which is really crucial. And I really like react-router's API.

I don't think we should move too fast, there might be people out there who like this a lot better so we can just give it time to see if more people will help maintain this and solve those people's problems. I'm all for choices.

[omnidan]

Thanks for all the feedback 😄 Keeping both libraries sounds like a good plan - all we need to do now is get more people to contribute actively to redux-router (at the moment there are more issues opened every day than @Scarysize manages to look at / fix / close!) 😅

I agree that writing a "state of affairs" summary would be nice, it would also help @Scarysize and me make decisions for redux-router without having to ask @acdlite all the time.

@acdlite Don't feel bad, that's the point of open source projects - when you can't maintain them anymore, the community will join in and work on it. With proprietary projects that's not possible and the project would just die.

@idolize You can probably use some other library to convert the string to an object, but I still get your point.

@jlongster I totally agree with you, I opened this issue for this exact reason - I honestly didn't know what the best way to handle it would be, and I haven't used redux-simple-router yet so I couldn't tell if it's missing something that redux-router has or what switching feels like.

Switching guides would still be cool as some people might start out using redux-router and then realize redux-simple-router is a better solution, but also the other way around!

If anyone is interested in contributing, feel free to ping us in the discord channel! 😁

[bendiy]

This commit was a good switching guide for me to go from redux-router to redux-simple-router:
jlongster/react-redux-universal-hot-example@e13b935?diff=split

Like @kmudrick I was having issues getting redux-router working in a universal app.

[fhelwanger]

I like the "redux-simple-router" approach more, especially this:

We encourage direct access of react-router APIs.

By doing this, it's much simpler to stay "in sync" with new versions of react-router and also reduces a lot of complexity.

However, I would like to see these two libraries combined to maintain the redux ecosystem simpler. Sorry if my vision is wrong 😅

Maybe some questions to help it:

• What redux-router give us that redux-simple-router doesn't?
• Could these features be implemented on redux-simple-router in a simpler way?

[omnidan]

I would like to see these two libraries combined to maintain the redux ecosystem simpler.

That was my idea too, but it's really hard to combine them, as both libraries have totally different approaches.

[nickpresta]

We currently use redux-router in a decently sized (and growing) application. The main things we use, and like, are:

• router actions (pushState, etc)
• router.params
• in a few cases, router.location.key to determine when pages have "changed". We need this to interopt. with third-parties which require us to signal "new pages" to them (including first load).

If redux-simple-router supported these things, and it meant that there was a more actively maintained project which closely matched react-router, we would switch.

I really appreciate the work that @acdlite (et al.) has done (in redux-router and others) and would hate to see him burnout maintaining something he doesn't use anymore.

[jlongster]

If redux-simple-router supported these things, and it meant that there was a more actively maintained project which closely matched react-router, we would switch.

FWIW, you can do everything in both libraries. I'm not trying to say which is better, but the only different is API. redux-simple-router has an action you can fire updatePath to change the URL. And you get params simply on this.props in routing components, the way react-router was built to work. And you can detect when pages have changed by listening for an UPDATE_PATH action.

I think some people are confused that redux-router implements these features, but really react-router is the one that implements most of the work and this project was trying to re-expose the API in a redux way. But that is complicated, and redux-simple-router just tells you to use react-router APIs directly.

I'm going to add more examples to the project, but for now you can check out the port of react-redux-universal-hot-example.

[jlongster]

I really, really don't want to come across as confrontational. @acdlite and others have done great work. This is a great project and I'm sure a lot of people like this API better! But I saw an opportunity to do it differently so I'm just throwing it out there.

[Scarysize]

Soooo, before this thread gets lost in the issues abyss. I will just throw in some ideas:

How can make it easier for people to contribute?

I think this a big issue (badumtss). There are a lot of contributions, but for very specific problems people are dealing with and fixing themselves. A lot of major issues won´t really get tackled, because firstly, there are workarounds, secondly nobody cares about an issue if they aren't affected by it and thirdly it is like REALLY confusing and hard spot what the exact issue is and were to start fixing it. There are maybe 3-4 separate issues for maybe the same problem...maybe not, it´s hard to tell.
So, what may help (I myself am pretty new to this open source stuff, so maybe I have fundamentally wrong ideas...):

1. Identify the major issues: Make collection of separate issues relating to the same problem and communicate that this is one issue
2. Identify which issues are important for people: I think react-native uses something like this, with Product Pains(?). This potential contributors have good starting point.
3. Encourage people to implement their workarounds. Not sure on this one though...

On a side note: I am really thankful for every contribution and am kind of sad, that I don´t have the time to contribute (and im talking code) to this great project. I´m keeping up with issues, trying to point people in the right direction for their problem, but as mentioned above there isn´t anyone really working on fixing major issues or adding new features.

What´s your grasp on this? Let us know!

[duro]

I'm going to throw my 10 cents into the ring. I have been using redux router quite a bit and I have been really loving it's more in-depth integration with react-router. I have found many use cases where taking advantage of it's closer integration with the history module has allowed me to to create code that makes sense. I too am interested in seeing this module continue to evolve. I would not want to see it die.

[duro]

Just re-read this thread again, and I'm in the same boat as @nickpresta. We have found redux router incredibly helpful in our app, and we are using all the things he mentions. These are all things not really offered by redux-simple-router.

[marknutter]

I came here from a Hacker News thread about redux-simple-router to pretty much echo what I said there, which is to suggest that a hard dependency on React be avoided. I (and plenty of others) use Redux without React and as such would appreciate that same agnostic approach be extended to the ecosystem being built around Redux. Luckily, there are no down-vote buttons on Github so my comment might actually be seen here :-P

[zrosenbauer]

Hey everyone we are using Redux-router currently in our application soon to be launched (neighborhoods.com). I (and our other front-end engineer) would love to really contribute to this moving forward but prior to launch there is not much we can do! After holidays I will be back on to help out...thanks for all the effort guys.

[Scarysize]

@zrosenbauer that's great to here. If you have any questions you can just message us on Discord

[mjrussell]

I'd like to throw out a suggestion I've thought about after porting an app from redux-router to redux-simple-router.

I think one thing that would be very beneficial would be to move the constants, actions, and middleware related to the historyApi into its own module because this could easily be used side by side with redux-simple-router or even shared between the two libraries. I think for anyone who uses these features in reudx-router this is a major hurdle to re-implement this functionality when considering a switch to redux-simple-router

[mmmurf]

I've been very happy with redux-simple-router, the only issue currently is the bug in google chrome for IOS that makes browserHistory not work.

[HriBB]

I use redux-router in my app and one thing I really like is that I can use router params from state in my reselect selectors.

[jcheroske]

I'm just wondering what the current status of this project is. Has the redux community settled on react-router-redux as the standard? Sorry if this has already been answered somewhere else.

[Scarysize]

@jcheroske I guess there are a few projects left, which use redux-router because react-router-redux hasn´t been released yet, when they started. Also I think most people realize, that most of the time react-router is enough for your app and you don´t need redux bindings. If you aren´t at a point where your REALLY need bindings, I would recommend not adding another dependency to your project. Otherwise react-router-redux is the more stable and better maintained solution. Though we haven´t received issues with this library for quite some time :-)

For the current state: As there are no major issues, nobody is working on anything. If something arises, we always try to solve it quickly. Also I´m trying to figure out if people are using the 2.0 version and, depending on feedback, merge this into the master branch.

[jcheroske]

Thank you, @Scarysize, for the in-depth heads-up. My project is in its initial stages, and I'm not actually sure if my requirements call for the router state to be in redux, but I can't help but think I'd like to just put it in there anyway.

I've written a small module that generates various actions when certain reactive data changes in Meteor. For example, whenever the status of the logged-in user changes, an action is fired and the store state is mutated. Now I'd like to go beyond just importing the Meteor state into redux, and actually create some behavior. Can you (or anyone else here) suggest an approach and/or one of the redux router libraries for the following bit of functionality?

• If there is no logged in user, or if the user is logged out for any reason (admin, expired token, etc.) redirect them to the login page.

There will be an action fired when the user is logged out, and there will be store state that also indicates there is no user. What is the best way to do this? I'm thinking that using a saga might be best, but maybe just subscribing to the store state would be better. Honestly, I am so new to redux that I have no idea what's an anti-pattern. Does this use-case warrant having the router state in redux?

[mjrussell]

@jcheroske you should check out my small HOC library for helping with authentication and redux. It supports both redux-router, react-router-redux and just using React Router without a redux biding. Theres an example that shows just the behavior you are describing - https://github.com/mjrussell/redux-auth-wrapper

[jcheroske]

@Mjrussel, thank you for the tip, and for the library! Let's continue the discussion over there.

[oyeanuj]

@Scarysize What does the beta8 tag indicate now? Its been 6 months, hence the question. Is it just more of a formality, or are you planning to make more changes before calling it v1 done?

[Scarysize]

@oyeanuj No, I don´t think there are going to be any changes to the v1 anymore. I will talk to @mjrussell and then I guess we will release the current beta8 as 1.0.0.

[mjrussell]

Yeah I agree @Scarysize. Definitely think the React Router 1 supported version should be versioned without the beta tag. Not sure about the React Router 2 version, I don't have any plans to add features to it. Also with semver no one should get an auto upgrade so it's pretty safe to do a 2.0 release with it.

[Scarysize]

redux-router@latest (default) is now 2.0.0
redux-router@previous is now 1.0.0

Also I pushed a separate branch for v1, because it got somehow lost in the v2 commits.

[msuperina]

Hi I don't know if here is the right forum but this discussion motivated me to write this article http://blog.scottlogic.com/2017/03/09/relogic-2.html and the libraries it describes. Let me know if this message is not appropriate and I will delete it.