20 ms·

A Simple Way to Route with Redux

124 points by jlongster 11y ago

deleted 11y ago
[deleted]
marknutter 11y ago
It's disappointing that this depends on React's router, considering Redux is an agnostic framework. Unless I'm reading something wrong here..
- methyl 11y ago
  Purpose of this library is to be able to use react-router with Redux, that's what the dependency comes from.
  - marknutter 11y ago
    I understand that, and it's disappointing. I was excited about the prospect of a very lightweight router to use with Redux that didn't require React as a dependency. Oh well, I guess that's why Github has a "fork" button :)
    - lemevi 11y ago
      What are you using if not React? Why wouldn't you use React if you are using Redux?
      - bananaoomarang 11y ago
        Redux is just a set of tools to manage a state tree, doesn't depend on React specifically, and no real reason have it as the view layer other than it being in widespread use.
        lemevi 11y ago
        Right, but I'm asking why not react in this specific instance.
      - colordrops 11y ago
        I'm not the OP, but I'm working on a project that originally did not use Redux, but was integrated after the fact. It is using a presentation layer other than React, and thus we would not be able to use this router.
        marknutter 11y ago
        Exactly my scenario at work.
      - marknutter 11y ago
        Aurelia at work and for personal projects I use virtual-dom (https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom). There are plenty of (IMO) better view libraries out there that can be nicely paired with Redux, so naturally it's upsetting to see libraries with "redux" in the title that also have a hard React dependency. It's also upsetting that I'm getting down-voted for having this opinion.
        lemevi 11y ago
        Interesting. Personally I have a hard time seeing how anything that requires separate templates as being better than React. I never want to go back to that. There's hardly a need to query elements. The only time one does is when using non-react libraries or doing some animation logic. And so there's no state in the HTML, and no need to render HTML elements that aren't visible. Virtual DOM seems ok except I find looking at JSX to be much easier on the eyes than JavaScript.
        marknutter 11y ago
        There's no need to query elements with Aurelia either, and it also does not render anything that isn't visible. I only use Aurelia because that's what they were using when I got hired, but for my personal projects I use Virtual DOM. React is just way too heavy for my needs and if I'm going to put markup in my JS files I might as well just use Hyperscript so it actually is javascript. By pairing virtual-dom with redux, my entire application's state, including how the UI currently looks, is held in one large immutable object which I just apply reducers to when I want to change the interface. React, and all the other modern front-end frameworks, still have to deal with state living in two places (in stores and in the DOM) whereas in my apps' state only lives in once place - the Redux store. Don't get me wrong, React pushed front-end development forward in a big way, but a lot of cool stuff has come out of the woodwork in response to it that is definitely worth checking out. I'm more interested true functional-reactive web libraries than React. Cycle, Elm, Ohm, and Mercury are a few I would recommend checking out.
- kevan 11y ago
  From the post: > After integrating redux and react-router in my site, I extracted my solution to a new project: redux-simple-router. The goal is simple: let react-router do all the work. They have already developed very elegant APIs for implementing routing components, and you should just use them. The explicit goal of the project is to take advantage of react-router's existing tools when used with redux, it doesn't make any sense to lament that it depends on react-router.
  - marknutter 11y ago
    Then why not call the project redux-simple-react-router or something to that effect, given that it's written for an agnostic library but has a hard dependency on a third library? It's easy to get caught up in one's own bubble but you should be aware that there are plenty of people out there who don't use React but like some of the libraries and patterns that came out of that community.
- chlee 11y ago
  A slightly tangential question. What is the benefit of using react-router (I am assuming on the client side) versus using a server side router that comes with whatever web framework that you are using?
  - jgautsch 11y ago
    Two things I've found beneficial are: In a single page app, your client routes (representing individual views) don't have to map directly to your server side routes, which gives you the ability to have pages/views that don't require a server roundtrip. You can also cache frequently used data on the client and use them on multiple "pages" as you navigate through your client side routes/pages, loading "page" specific data from your API as needed. So in general it gives you more tools/options for building a snappier app.
    - tomcam 11y ago
      Wow, thanks. That brought a whole bunch of client vs server issues into focus for me.
    - matt4077 11y ago
      I'm not completely firm on this (and appreciate corrections) but it appears that you could get these benefits without a client-side router? I. e. it's perfectly feasibly to render a different page/view when a link is clicked without a router by just changing the state and swapping out components. As I understand it, client-side routers manage the relationship between URLs and state. The parts of state that are relevant when a page/view might be bookmarked/shared etc. are encoded in the URL, and a given URL can be decoded into an initial state. I'm now wondering if the first direction (state->url) couldn't just be thought of as a component. It just extracts parts of state and renders it into a string. The other direction would then be an action.
      - jgautsch 11y ago
        > I'm now wondering if the first direction (state->url) couldn't just be thought of as a component. It just extracts parts of state and renders it into a string. The other direction would then be an action. The specific component/state rendered is a reaction to the URL, not the other way around (this can get cloudy with semantics though). Keeping the URL and the current page state in sync takes the form of updating the path, and having your application react to that. You're right it is perfectly feasible to render a different page/view when a link is clicked without a client-side router library, but the "swapping out components" part can get tricky for non-trivial cases like a hierarchical UI, or components that need to consume URL params. A client-side router like react-router abstracts away a lot of the hard stuff you'd quickly run into on your own if A.) your app has navigation, and B.) you want to have URLs associated to views/states.
- pluma 11y ago
  Contrary to what the blog post and the docs indicate, it doesn't seem to actually require you to use react-router, it just requires you to use history (which is neither specific to React nor to the browser). None of the API calls seem to ever have access to react-router (only history).
iamlacroix 11y ago
I recently switched to this library from Redux Router for a project, after having trouble with server-side routing. It really is simple, as stated in his title, and I would definitely recommend it if anyone is using Redux and React Router.
- Lazare 11y ago
  I've been struggling with redux-router all week, and was just about to spend today trying to switch to this project. Glad to hear your experience. :)
  - AndrusAsumets 11y ago
    Yeah, same here. Almost decided to ditch the whole redux-router for good before I saw this thread.
theduro 11y ago
This library lack some of the super powerful features that really made me fall in love with redux-router. Being able to get access to params was huge, and having action creators to pushState and replaceState was also huge.
- jlongster 11y ago
  `updatePath` is an action creator, and there's a PR to rename it to `pushPath` and add `replacePath`. And you shouldn't access route params outside of a router component anyway. (EDIT: ok, the last statement was a simplification. But generally you don't need to, but you could manually move data into the state if you needed to)
  - theduro 11y ago
    I get that, but still no access to params and the ability to change them is still a boon for me. I often will use stand to store some basic state for deep linking certain views. For example a data grid and the sort or filter options. I was able to very elegantly execute this with redux-router and its full exposure of the entire route object and API pairity to pushState and replaceState
    - jlongster 11y ago
      That's great! Keep using redux-router then. I think you'd find that there's another pattern that works too, but there are multiple ways to do it.
skrebbel 11y ago
I suspect my knowledge is behind the times, but I never understood the appeal of putting stuff like "current thread" in the app state at all. To me, it makes much more sense if the stores (or the single data tree, in the redux case) just contain the flat dumb data, and the URL is used to pick the relevant data that the components need. This way, no state is duplicated anywhere, the stores are dumb, and the URL is leading. This is how most server side MVC frameworks work too, it makes server-side rendering super simple (even with shared app state between users), it fits with RESTful designs, it forces you to design state into URLs so users can share links by definition, and so on. It just seems obvious to me. But somehow, Flux and most things derived from it seem to disagree and insist on storing the "this is what the user looks at right now" information in the application state. To me, that hopelessly convolutes things. But I've been wrong before and I'd like to learn. Can anyone explain to me why that's better? I might just be a conservative, grumpy old man here.
- matt4077 11y ago
  There may be some state that belongs in the URL and some that doesn't. The threat currently read should certainly be in the URL to facilitate sharing/bookmarking etc. But, for example, the state of some checkboxes or a dropdown or values in input element – while being part of state – don't feel like they belong in the URL. I've actually been struggling with some of these. For example, whether a dropdown is expanded or not is state, but it just doesn't feel 'big' enough to even be in the reflux store. Plus it turns out to be a major hassle to implement such a dropdown, with actions firing the new state all the way up to the store and the state then being passed down the whole chain of components. Following redux orthodoxy here also precludes you from using existing libraries (bootstrap/jquery) and kinda leads to reinventing the wheel. I had no idea how much consideration a simple dropdown takes until I looked at the bootstrap/jquery source for it.
  - iLoch 11y ago
    I think it's the opinion of most React developers that state specifically pertaining to the presentation of UI controls (and not the general UI, which of course depends on Flux state) can be left in the React component. They do, after all, support having their own state - so that functionality should be utilized. Also declutters your app state.
Kiro 11y ago
So why so we want the URL in the state? What's the use case?
- jgautsch 11y ago
  One use case of having URL in the state (from the lib's README: https://github.com/jlongster/redux-simple-router https://github.com/jlongster/redux-simple-router) is that you can snapshot/serialize the app state, and load it up later and see the same thing. This can be useful for development and debugging. It's also worth mentioning that this lib also provides a really useful action creator- updatePath(). It allows you to navigate from other action creators, for example, in response to a successful AJAX call. You could achieve that a couple other ways as well, but this is the simplest/cleanest way I've seen so far.
  - Kiro 11y ago
    Thanks. updatePath is actually something I've been missing so that's great.
rattray 11y ago
> This is what redux-router attempts to do, but it's very complicated and prone to bugs. redux-router is still in beta, so this isn't entirely fair.
- cjhveal 11y ago
  I think the point is that serializing the entire react-router state into a redux store is in itself barking up the wrong tree, not that their approach is complicated or implemented in a buggy manner, per se.
- chrisacree 11y ago
  I think the "still in beta" argument doesn't hold up so well. Many projects now stay in more-or-less permanent "beta", just as a sign that they're open to significant changes in the future. With React libraries in particular, the ecosystem is still evolving so fast it seems relevant to note which are bug-prone, popular, etc, just to try and predict which will still be alive in a year.
rattray 11y ago
There's an open issue to replace redux-router with this package: https://github.com/rackt/redux-router/issues/172 https://github.com/rackt/redux-router/issues/172
sideproject 11y ago
Javacript moves fast (everybody knows that...). React and the tools around also move very quickly. I've been delaying learning React for awhile. After a period of ranting about "another JS library, another JS tool etc etc!!", I got tired of my ranting and have been giving a decent go at picking up React and a myriad of related tools (webpack, flux, react-router...). It turns out, if you have some experience of framework, whether it be AngularJS or Backbone (I come from BackboneJS and Marionette background), it doesn't take you too long to learn these things. I signed up for Egghead, searched around for awhile for the latest relevant tutorials, opened up many Chrome tabs and jumped around different places, but after a week, things are falling into places (JOY!). Learning part is frustrating, because there are references to old versions, old tutorials and you have to somehow mine through to make sense for yourself. But what isn't thesedays? I haven't picked up redux properly yet, but now I get Flux, I don't think it'll take too long before applying it. Redux Router? Bring it on!!
cubano 11y ago
Call me old (yes I am!) fashioned, but would it be too much to ask to see some sort of example app using said widget in the post? This is the second article I've been interested in today here on HN that seems, to me at least, to go on and on extolling the virtues of said framework/extension/etc, and in the end gives absolutely no hint of how to use it. Yes yes I know...farts like me are behind the curve/too slow/fat/old/stupid etc to understand all this modernity, but really, is it too much to ask for a small example of the Greatness?
- Lazare 11y ago
  Very fair point, however... ...in this case, it's not a widget, but a routing library. Actually a slightly nicer wrapping library around the same base routing library used by basically every React project, which means that for the user, it'll look exactly like every project that doesn't use it too. The only thing to "see" is basically the API docs. (That being said, maybe that could be made clearer in the blog post...?)
  - jlongster 11y ago
    This post was strictly intended for current users of redux and react-router. That could be included yes, but I have limited time and I'd rather publish blog posts rather than languish in my "drafts" folder. I can add a few things to this though.
asimjalis 11y ago
Nice pictures. How did you make them?
- lauritzsh 11y ago
  I am curious too, really refreshing look. I would guess it's hand-drawn with something like Paper, the "smudges" reminds me of that app. https://www.fiftythree.com/paper https://www.fiftythree.com/paper
capkutay 11y ago
I personally agree with and admire the methodology behind Redux, but I'm cautious about using it because it's right at the bleeding edge of web technologies (which we all know are rapidly changing).
losvedir 11y ago
As someone who's mainly just used react for simple components, when is the right time to think about pulling in redux? I'm getting by with just react, but it seems like at some complexity level everyone recommends a flux library (and mostly redux these days). Is it when you have multiple component trees on the page? When AJAX requests are involved? Or do people familiar with redux just drop it in from the very start even on simple components?
- insin 11y ago
  Dan Abramov wrote a blog post a while back with a bunch of "You might need Flux if..." use cases, which might be handy: https://medium.com/swlh/the-case-for-flux-379b7d1982c6 https://medium.com/swlh/the-case-for-flux-379b7d1982c6
- jroitgrund 11y ago
  It makes everything easier to test and reason about at the cost of little overhead (wrap your top-level routing components with 'connect', add a <Provider></Provider> wrapper around your <Router>). If you already have a lot of behavior defined it might take a little while to convert it all to reducers (action + currentState -> newState functions) but it's a pretty simple refactor.
jiyinyiyong 11y ago
We got a router too for the same reason that Redux is complicated(and at that time redux-router was not released) https://github.com/teambition/router-view https://github.com/teambition/router-view And it's demonstrated at here: http://r.nodejs-china.org/#/ http://r.nodejs-china.org/#/

124 points by jlongster 11y ago

deleted 11y ago

[deleted]

It's disappointing that this depends on React's router, considering Redux is an agnostic framework. Unless I'm reading something wrong here..

methyl 11y ago
Purpose of this library is to be able to use react-router with Redux, that's what the dependency comes from.
- marknutter 11y ago
  I understand that, and it's disappointing. I was excited about the prospect of a very lightweight router to use with Redux that didn't require React as a dependency. Oh well, I guess that's why Github has a "fork" button :)
  - lemevi 11y ago
    What are you using if not React? Why wouldn't you use React if you are using Redux?
    - bananaoomarang 11y ago
      Redux is just a set of tools to manage a state tree, doesn't depend on React specifically, and no real reason have it as the view layer other than it being in widespread use.
      - lemevi 11y ago
        Right, but I'm asking why not react in this specific instance.
    - colordrops 11y ago
      I'm not the OP, but I'm working on a project that originally did not use Redux, but was integrated after the fact. It is using a presentation layer other than React, and thus we would not be able to use this router.
      - marknutter 11y ago
        Exactly my scenario at work.
    - marknutter 11y ago
      Aurelia at work and for personal projects I use virtual-dom (https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom). There are plenty of (IMO) better view libraries out there that can be nicely paired with Redux, so naturally it's upsetting to see libraries with "redux" in the title that also have a hard React dependency. It's also upsetting that I'm getting down-voted for having this opinion.
      - lemevi 11y ago
        Interesting. Personally I have a hard time seeing how anything that requires separate templates as being better than React. I never want to go back to that. There's hardly a need to query elements. The only time one does is when using non-react libraries or doing some animation logic. And so there's no state in the HTML, and no need to render HTML elements that aren't visible. Virtual DOM seems ok except I find looking at JSX to be much easier on the eyes than JavaScript.
        marknutter 11y ago
        There's no need to query elements with Aurelia either, and it also does not render anything that isn't visible. I only use Aurelia because that's what they were using when I got hired, but for my personal projects I use Virtual DOM. React is just way too heavy for my needs and if I'm going to put markup in my JS files I might as well just use Hyperscript so it actually is javascript. By pairing virtual-dom with redux, my entire application's state, including how the UI currently looks, is held in one large immutable object which I just apply reducers to when I want to change the interface. React, and all the other modern front-end frameworks, still have to deal with state living in two places (in stores and in the DOM) whereas in my apps' state only lives in once place - the Redux store. Don't get me wrong, React pushed front-end development forward in a big way, but a lot of cool stuff has come out of the woodwork in response to it that is definitely worth checking out. I'm more interested true functional-reactive web libraries than React. Cycle, Elm, Ohm, and Mercury are a few I would recommend checking out.
kevan 11y ago
From the post: > After integrating redux and react-router in my site, I extracted my solution to a new project: redux-simple-router. The goal is simple: let react-router do all the work. They have already developed very elegant APIs for implementing routing components, and you should just use them. The explicit goal of the project is to take advantage of react-router's existing tools when used with redux, it doesn't make any sense to lament that it depends on react-router.
- marknutter 11y ago
  Then why not call the project redux-simple-react-router or something to that effect, given that it's written for an agnostic library but has a hard dependency on a third library? It's easy to get caught up in one's own bubble but you should be aware that there are plenty of people out there who don't use React but like some of the libraries and patterns that came out of that community.
chlee 11y ago
A slightly tangential question. What is the benefit of using react-router (I am assuming on the client side) versus using a server side router that comes with whatever web framework that you are using?
- jgautsch 11y ago
  Two things I've found beneficial are: In a single page app, your client routes (representing individual views) don't have to map directly to your server side routes, which gives you the ability to have pages/views that don't require a server roundtrip. You can also cache frequently used data on the client and use them on multiple "pages" as you navigate through your client side routes/pages, loading "page" specific data from your API as needed. So in general it gives you more tools/options for building a snappier app.
  - tomcam 11y ago
    Wow, thanks. That brought a whole bunch of client vs server issues into focus for me.
  - matt4077 11y ago
    I'm not completely firm on this (and appreciate corrections) but it appears that you could get these benefits without a client-side router? I. e. it's perfectly feasibly to render a different page/view when a link is clicked without a router by just changing the state and swapping out components. As I understand it, client-side routers manage the relationship between URLs and state. The parts of state that are relevant when a page/view might be bookmarked/shared etc. are encoded in the URL, and a given URL can be decoded into an initial state. I'm now wondering if the first direction (state->url) couldn't just be thought of as a component. It just extracts parts of state and renders it into a string. The other direction would then be an action.
    - jgautsch 11y ago
      > I'm now wondering if the first direction (state->url) couldn't just be thought of as a component. It just extracts parts of state and renders it into a string. The other direction would then be an action. The specific component/state rendered is a reaction to the URL, not the other way around (this can get cloudy with semantics though). Keeping the URL and the current page state in sync takes the form of updating the path, and having your application react to that. You're right it is perfectly feasible to render a different page/view when a link is clicked without a client-side router library, but the "swapping out components" part can get tricky for non-trivial cases like a hierarchical UI, or components that need to consume URL params. A client-side router like react-router abstracts away a lot of the hard stuff you'd quickly run into on your own if A.) your app has navigation, and B.) you want to have URLs associated to views/states.
pluma 11y ago
Contrary to what the blog post and the docs indicate, it doesn't seem to actually require you to use react-router, it just requires you to use history (which is neither specific to React nor to the browser). None of the API calls seem to ever have access to react-router (only history).

iamlacroix 11y ago

I recently switched to this library from Redux Router for a project, after having trouble with server-side routing. It really is simple, as stated in his title, and I would definitely recommend it if anyone is using Redux and React Router.

Lazare 11y ago
I've been struggling with redux-router all week, and was just about to spend today trying to switch to this project. Glad to hear your experience. :)
- AndrusAsumets 11y ago
  Yeah, same here. Almost decided to ditch the whole redux-router for good before I saw this thread.

theduro 11y ago

This library lack some of the super powerful features that really made me fall in love with redux-router. Being able to get access to params was huge, and having action creators to pushState and replaceState was also huge.

jlongster 11y ago
`updatePath` is an action creator, and there's a PR to rename it to `pushPath` and add `replacePath`. And you shouldn't access route params outside of a router component anyway. (EDIT: ok, the last statement was a simplification. But generally you don't need to, but you could manually move data into the state if you needed to)
- theduro 11y ago
  I get that, but still no access to params and the ability to change them is still a boon for me. I often will use stand to store some basic state for deep linking certain views. For example a data grid and the sort or filter options. I was able to very elegantly execute this with redux-router and its full exposure of the entire route object and API pairity to pushState and replaceState
  - jlongster 11y ago
    That's great! Keep using redux-router then. I think you'd find that there's another pattern that works too, but there are multiple ways to do it.

skrebbel 11y ago

I suspect my knowledge is behind the times, but I never understood the appeal of putting stuff like "current thread" in the app state at all. To me, it makes much more sense if the stores (or the single data tree, in the redux case) just contain the flat dumb data, and the URL is used to pick the relevant data that the components need. This way, no state is duplicated anywhere, the stores are dumb, and the URL is leading. This is how most server side MVC frameworks work too, it makes server-side rendering super simple (even with shared app state between users), it fits with RESTful designs, it forces you to design state into URLs so users can share links by definition, and so on. It just seems obvious to me. But somehow, Flux and most things derived from it seem to disagree and insist on storing the "this is what the user looks at right now" information in the application state. To me, that hopelessly convolutes things. But I've been wrong before and I'd like to learn. Can anyone explain to me why that's better? I might just be a conservative, grumpy old man here.

matt4077 11y ago
There may be some state that belongs in the URL and some that doesn't. The threat currently read should certainly be in the URL to facilitate sharing/bookmarking etc. But, for example, the state of some checkboxes or a dropdown or values in input element – while being part of state – don't feel like they belong in the URL. I've actually been struggling with some of these. For example, whether a dropdown is expanded or not is state, but it just doesn't feel 'big' enough to even be in the reflux store. Plus it turns out to be a major hassle to implement such a dropdown, with actions firing the new state all the way up to the store and the state then being passed down the whole chain of components. Following redux orthodoxy here also precludes you from using existing libraries (bootstrap/jquery) and kinda leads to reinventing the wheel. I had no idea how much consideration a simple dropdown takes until I looked at the bootstrap/jquery source for it.
- iLoch 11y ago
  I think it's the opinion of most React developers that state specifically pertaining to the presentation of UI controls (and not the general UI, which of course depends on Flux state) can be left in the React component. They do, after all, support having their own state - so that functionality should be utilized. Also declutters your app state.

Kiro 11y ago

So why so we want the URL in the state? What's the use case?

jgautsch 11y ago
One use case of having URL in the state (from the lib's README: https://github.com/jlongster/redux-simple-router https://github.com/jlongster/redux-simple-router) is that you can snapshot/serialize the app state, and load it up later and see the same thing. This can be useful for development and debugging. It's also worth mentioning that this lib also provides a really useful action creator- updatePath(). It allows you to navigate from other action creators, for example, in response to a successful AJAX call. You could achieve that a couple other ways as well, but this is the simplest/cleanest way I've seen so far.
- Kiro 11y ago
  Thanks. updatePath is actually something I've been missing so that's great.

rattray 11y ago

> This is what redux-router attempts to do, but it's very complicated and prone to bugs. redux-router is still in beta, so this isn't entirely fair.

cjhveal 11y ago
I think the point is that serializing the entire react-router state into a redux store is in itself barking up the wrong tree, not that their approach is complicated or implemented in a buggy manner, per se.
chrisacree 11y ago
I think the "still in beta" argument doesn't hold up so well. Many projects now stay in more-or-less permanent "beta", just as a sign that they're open to significant changes in the future. With React libraries in particular, the ecosystem is still evolving so fast it seems relevant to note which are bug-prone, popular, etc, just to try and predict which will still be alive in a year.

rattray 11y ago

There's an open issue to replace redux-router with this package: https://github.com/rackt/redux-router/issues/172 https://github.com/rackt/redux-router/issues/172

sideproject 11y ago

Javacript moves fast (everybody knows that...). React and the tools around also move very quickly. I've been delaying learning React for awhile. After a period of ranting about "another JS library, another JS tool etc etc!!", I got tired of my ranting and have been giving a decent go at picking up React and a myriad of related tools (webpack, flux, react-router...). It turns out, if you have some experience of framework, whether it be AngularJS or Backbone (I come from BackboneJS and Marionette background), it doesn't take you too long to learn these things. I signed up for Egghead, searched around for awhile for the latest relevant tutorials, opened up many Chrome tabs and jumped around different places, but after a week, things are falling into places (JOY!). Learning part is frustrating, because there are references to old versions, old tutorials and you have to somehow mine through to make sense for yourself. But what isn't thesedays? I haven't picked up redux properly yet, but now I get Flux, I don't think it'll take too long before applying it. Redux Router? Bring it on!!

cubano 11y ago

Call me old (yes I am!) fashioned, but would it be too much to ask to see some sort of example app using said widget in the post? This is the second article I've been interested in today here on HN that seems, to me at least, to go on and on extolling the virtues of said framework/extension/etc, and in the end gives absolutely no hint of how to use it. Yes yes I know...farts like me are behind the curve/too slow/fat/old/stupid etc to understand all this modernity, but really, is it too much to ask for a small example of the Greatness?

Lazare 11y ago
Very fair point, however... ...in this case, it's not a widget, but a routing library. Actually a slightly nicer wrapping library around the same base routing library used by basically every React project, which means that for the user, it'll look exactly like every project that doesn't use it too. The only thing to "see" is basically the API docs. (That being said, maybe that could be made clearer in the blog post...?)
- jlongster 11y ago
  This post was strictly intended for current users of redux and react-router. That could be included yes, but I have limited time and I'd rather publish blog posts rather than languish in my "drafts" folder. I can add a few things to this though.

asimjalis 11y ago

Nice pictures. How did you make them?

lauritzsh 11y ago
I am curious too, really refreshing look. I would guess it's hand-drawn with something like Paper, the "smudges" reminds me of that app. https://www.fiftythree.com/paper https://www.fiftythree.com/paper

capkutay 11y ago

I personally agree with and admire the methodology behind Redux, but I'm cautious about using it because it's right at the bleeding edge of web technologies (which we all know are rapidly changing).

losvedir 11y ago

As someone who's mainly just used react for simple components, when is the right time to think about pulling in redux? I'm getting by with just react, but it seems like at some complexity level everyone recommends a flux library (and mostly redux these days). Is it when you have multiple component trees on the page? When AJAX requests are involved? Or do people familiar with redux just drop it in from the very start even on simple components?

insin 11y ago
Dan Abramov wrote a blog post a while back with a bunch of "You might need Flux if..." use cases, which might be handy: https://medium.com/swlh/the-case-for-flux-379b7d1982c6 https://medium.com/swlh/the-case-for-flux-379b7d1982c6
jroitgrund 11y ago
It makes everything easier to test and reason about at the cost of little overhead (wrap your top-level routing components with 'connect', add a <Provider></Provider> wrapper around your <Router>). If you already have a lot of behavior defined it might take a little while to convert it all to reducers (action + currentState -> newState functions) but it's a pretty simple refactor.

jiyinyiyong 11y ago

We got a router too for the same reason that Redux is complicated(and at that time redux-router was not released) https://github.com/teambition/router-view https://github.com/teambition/router-view And it's demonstrated at here: http://r.nodejs-china.org/#/ http://r.nodejs-china.org/#/