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.
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.
well, when you use redux to manage the router state, you get the best of both worlds.
"current thread" doesn't need to be stored in the state in an explicit way. rather, you just need to be able to derive the "current thread" (or whatever) from the state.
so, your state contains the current route, and you use that to derive the "current thread" and then if redux has any state corresponding to that thread (or whatever) you can get that, too.
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?
...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...?)
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!!
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?
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.
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.
`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)
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).
One use case of having URL in the state (from the lib's README: 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.
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.
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.
> 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.
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).
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?
[+] [-] skrebbel|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] snappy173|10 years ago|reply
"current thread" doesn't need to be stored in the state in an explicit way. rather, you just need to be able to derive the "current thread" (or whatever) from the state.
so, your state contains the current route, and you use that to derive the "current thread" and then if redux has any state corresponding to that thread (or whatever) you can get that, too.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] coldtea|10 years ago|reply
So the SPA's state is different than just "we're now pointing to this resource" -- much more full and complex.
[+] [-] cubano|10 years ago|reply
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|10 years ago|reply
...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...?)
[+] [-] sideproject|10 years ago|reply
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!!
[+] [-] iamlacroix|10 years ago|reply
It really is simple, as stated in his title, and I would definitely recommend it if anyone is using Redux and React Router.
[+] [-] Lazare|10 years ago|reply
[+] [-] losvedir|10 years ago|reply
[+] [-] insin|10 years ago|reply
[+] [-] jroitgrund|10 years ago|reply
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.
[+] [-] theduro|10 years ago|reply
[+] [-] jlongster|10 years ago|reply
(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)
[+] [-] jiyinyiyong|10 years ago|reply
https://github.com/teambition/router-view
And it's demonstrated at here:
http://r.nodejs-china.org/#/
[+] [-] rattray|10 years ago|reply
https://github.com/rackt/redux-router/issues/172
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] capkutay|10 years ago|reply
[+] [-] Kiro|10 years ago|reply
[+] [-] jgautsch|10 years ago|reply
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.
[+] [-] asimjalis|10 years ago|reply
[+] [-] lauritzsh|10 years ago|reply
https://www.fiftythree.com/paper
[+] [-] rattray|10 years ago|reply
redux-router is still in beta, so this isn't entirely fair.
[+] [-] cjhveal|10 years ago|reply
[+] [-] chrisacree|10 years ago|reply
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.
[+] [-] marknutter|10 years ago|reply
[+] [-] kevan|10 years ago|reply
> 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.
[+] [-] methyl|10 years ago|reply
[+] [-] pluma|10 years ago|reply
[+] [-] chlee|10 years ago|reply
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?