5 ms·

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

methyl 11y ago
Purpose of this library is to be able to use react-router with Redux, that's what the dependency comes from.
- marknutter 11y ago
  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 :)
  - lemevi 11y ago
    What are you using if not React? Why wouldn't you use React if you are using Redux?
    - bananaoomarang 11y ago
      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.
      - lemevi 11y ago
        Right, but I'm asking why not react in this specific instance.
    - colordrops 11y ago
      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.
      - marknutter 11y ago
        Exactly my scenario at work.
    - marknutter 11y ago
      Aurelia at work and for personal projects I use virtual-dom (https://github.com/Matt-Esch/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.
      - lemevi 11y ago
        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.
        marknutter 11y ago
        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.
kevan 11y ago
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 make any sense to lament that it depends on react-router.
- marknutter 11y ago
  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.
chlee 11y ago
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?
- jgautsch 11y ago
  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.
  - tomcam 11y ago
    Wow, thanks. That brought a whole bunch of client vs server issues into focus for me.
  - matt4077 11y ago
    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.
    - jgautsch 11y ago
      > 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.
pluma 11y ago
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).

methyl 11y ago

Purpose of this library is to be able to use react-router with Redux, that's what the dependency comes from.

marknutter 11y ago
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 :)
- lemevi 11y ago
  What are you using if not React? Why wouldn't you use React if you are using Redux?
  - bananaoomarang 11y ago
    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.
    - lemevi 11y ago
      Right, but I'm asking why not react in this specific instance.
  - colordrops 11y ago
    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.
    - marknutter 11y ago
      Exactly my scenario at work.
  - marknutter 11y ago
    Aurelia at work and for personal projects I use virtual-dom (https://github.com/Matt-Esch/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.
    - lemevi 11y ago
      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.
      - marknutter 11y ago
        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.

kevan 11y ago

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 make any sense to lament that it depends on react-router.

marknutter 11y ago
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.

chlee 11y ago

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?

jgautsch 11y ago
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.
- tomcam 11y ago
  Wow, thanks. That brought a whole bunch of client vs server issues into focus for me.
- matt4077 11y ago
  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.
  - jgautsch 11y ago
    > 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.

pluma 11y ago

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