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

31–40 of 57 posts

Re: A Simple Way to Route with Redux

#31

Post by marknutter »

kevan wrote: post #8
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..

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…

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.

Re: A Simple Way to Route with Redux

#32

Post by marknutter »

colordrops wrote: post #28
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?

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.

Exactly my scenario at work.

Re: A Simple Way to Route with Redux

#33

Post by cjhveal »

rattray wrote: post #25

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

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.

Re: A Simple Way to Route with Redux

#34

Post by guscost »

matt4077 wrote: post #29
guscost wrote: post #27

Earlier quoted context omitted.

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?

The global KW object is just a namespace for the widget wrapper components. You'd have to reference the Kendo UI Core library and then the KW.js script before rendering your components containing e.g. as in the readme.

Internally the Kendo library is going to maintain its own state and manipulate the DOM elements needed for each widget, and I only know a bit about how that works. Most of these wrappers only run render() once because React would throw all kinds of errors if it tried to diff the DOM inside the components.

Updates are handled in componentWillReceiveProps, and whenever the component can be updated with the new props without destroying and recreating itself, the updates happen via the Kendo API (after the wrapper checks if the new value is different). This means that for common use cases these wrappers should perform just about as well as the widgets do normally. Also every controllable setting is exposed as a prop, and the props are synchronized on every update. Props that are not passed in are reset to the defaults, meaning these widgets should appear stateless to the containing component.

The react-kendo project[0] uses some very cool introspection to provide full support for all the Kendo widgets, and it looks like it should be reliable and stateless. However it destroys and rebuilds the widget on every update. While that probably isn't going to be a huge performance hit it certainly makes a difference.

https://github.com/tjwebb/react-kendo

Re: A Simple Way to Route with Redux

#35

Post by jgautsch »

matt4077 wrote: post #21
jgautsch wrote: post #14

Earlier quoted context omitted.

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

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

Re: A Simple Way to Route with Redux

#36

Post by jgautsch »

Kiro wrote: post #23

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

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.

Re: A Simple Way to Route with Redux

#37

Post by theduro »

jlongster wrote: post #13
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)

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

Re: A Simple Way to Route with Redux

#38

Post by pluma »

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

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

Re: A Simple Way to Route with Redux

#39

Post by sideproject »

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

Re: A Simple Way to Route with Redux

#40

Post by snappy173 »

matt4077 wrote: post #22
snappy173 wrote: post #18

Earlier quoted context omitted.

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.

In that case, you can have a redux state reducer look for navigation actions, and set current thread. Either way works well with the flux/redux mental model. And in either case, you'll have to implement logic for mapping route -> current thread and vice versa ...
Post reply on HN