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

51–57 of 57 posts

Re: A Simple Way to Route with Redux

#51

Post by insin »

losvedir wrote: post #48

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…

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

Re: A Simple Way to Route with Redux

#54

Post by jroitgrund »

losvedir wrote: post #48

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…

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 wrapper around your ).

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.

Re: A Simple Way to Route with Redux

#55

Post by AndrusAsumets »

Lazare wrote: post #10
iamlacroix wrote: post #4

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.

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

Yeah, same here. Almost decided to ditch the whole redux-router for good before I saw this thread.

Re: A Simple Way to Route with Redux

#56

Post by lemevi »

marknutter wrote: post #30
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?

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.

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.

Re: A Simple Way to Route with Redux

#57

Post by marknutter »

lemevi wrote: post #56
marknutter wrote: post #30

Earlier quoted context omitted.

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.

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

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.

Post reply on HN