A Simple Way to Route with Redux • Hacker News Board

Re: A Simple Way to Route with Redux

#21

Post by matt4077 » Wed, Nov 25, 2015, 8:38 PM UTC

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…

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.

Re: A Simple Way to Route with Redux

#22

Post by matt4077 » Wed, Nov 25, 2015, 8:39 PM UTC

snappy173 wrote: post #18

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…

This might just be personal preference, but it seems that "current thread" is the more pure representation of (that part) of the current state, and the URL/route should be the derived attribute.

Re: A Simple Way to Route with Redux

#23

Post by Kiro » Wed, Nov 25, 2015, 8:42 PM UTC

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

Re: A Simple Way to Route with Redux

#24

Post by iLoch » Wed, Nov 25, 2015, 8:45 PM UTC

matt4077 wrote: post #17

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

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.

Re: A Simple Way to Route with Redux

#25

Post by rattray » Wed, Nov 25, 2015, 8:49 PM UTC

> 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.

Re: A Simple Way to Route with Redux

#26

Post by rattray » Wed, Nov 25, 2015, 8:49 PM UTC

There's an open issue to replace redux-router with this package:

https://github.com/rackt/redux-router/issues/172

Re: A Simple Way to Route with Redux

#27

Post by guscost » Wed, Nov 25, 2015, 8:49 PM UTC

matt4077 wrote: post #17

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

For common components like Dropdowns, DatePickers, etc, I've been using Kendo UI Core with a set of simple wrappers to make them (mostly) stateless:

https://github.com/guscost/kendo-react-wrappers

Perhaps not acceptable for performance-critical or first-class consumer-facing UIs, but you get nice cross-browser compatibility and pre-built widgets that can be surprisingly complex.

Re: A Simple Way to Route with Redux

#28

Post by colordrops » Wed, Nov 25, 2015, 8:53 PM UTC

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?

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.

Re: A Simple Way to Route with Redux

#29

Post by matt4077 » Wed, Nov 25, 2015, 9:05 PM UTC

guscost wrote: post #27

matt4077 wrote: post #17

Earlier quoted context omitted.

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

For common components like Dropdowns, DatePickers, etc, I've been using Kendo UI Core with a set of simple wrappers to make them (mostly) stateless: https://github.com/guscost/kendo-react-wrappers Perhaps not acceptable for performance-critical or first-class consumer-facing UIs, but you get nice cross-browser compatibility and pre-built widgets that can be surprisingly complex.

So, if I see this correctly, these components save their state in a global object, and that is supposed to persist state on re-renders? I get how this can be considered somewhat 'dirty', but can you elaborate on the performance implications?

Re: A Simple Way to Route with Redux

#30

Post by marknutter » Wed, Nov 25, 2015, 9:06 PM UTC

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?

Aurelia at work and for personal projects I use 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.