Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Simple Way to Route with Redux

jlongster.com

Post reply on HN
Print view View original

11–20 of 57 posts

Re: A Simple Way to Route with Redux

#11

Post by bananaoomarang »

lemevi wrote: post #7
marknutter wrote: post #6

Earlier quoted context omitted.

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 :)

What are you using if not React? Why wouldn't you use React if you are using Redux?

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.

Re: A Simple Way to Route with Redux

#12

Post by theduro »

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.

Re: A Simple Way to Route with Redux

#13

Post by jlongster »

theduro wrote: post #12

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)

Re: A Simple Way to Route with Redux

#14

Post by jgautsch »

chlee wrote: post #9
marknutter wrote: post #3

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

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?

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.

Re: A Simple Way to Route with Redux

#15

Post by lemevi »

bananaoomarang wrote: post #11
lemevi wrote: post #7

Earlier quoted context omitted.

What are you using if not React? Why wouldn't you use React if you are using Redux?

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.

Right, but I'm asking why not react in this specific instance.

Re: A Simple Way to Route with Redux

#16

Post by skrebbel »

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.

Re: A Simple Way to Route with Redux

#17

Post by matt4077 »

skrebbel wrote: post #16

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 lea…

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.

Re: A Simple Way to Route with Redux

#18

Post by snappy173 »

skrebbel wrote: post #16

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 lea…

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.

Re: A Simple Way to Route with Redux

#19

Post by [deleted] »

skrebbel wrote: post #16

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 lea…

[deleted]

Re: A Simple Way to Route with Redux

#20

Post by tomcam »

jgautsch wrote: post #14
chlee wrote: post #9

Earlier quoted context omitted.

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?

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 d…

Wow, thanks. That brought a whole bunch of client vs server issues into focus for me.
Post reply on HN