3 ms·

State-Driven Routing with React, Redux, Selectors

10 points by thinkloop 10y ago

carsongross 10y ago
Routing is complex. There are a lot of disparate pieces that come together to give users the ability to navigate a site. There is the address bar ui element which displays a url string on screen. There is back/forward functionality accessible through buttons, keyboard shortcuts or other input methods. There are <a> links which navigate to new content in various ways. There is url input through the address bar. I appreciate a look into this world, but routing on the web isn't supposed to be very complex. One of the big simplicity wins of the web network architecture was that it was stateless almost everywhere, with hypertext as the engine of application state[1]. Anybody can write some HTML with some anchor tags and tie it to some routes declared in a server-side routing file. The back button will work. History will work. Refresh will work. Copy-and-pasting the URL into an email will work. It's so easy that even I can do it. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS
- thinkloop 10y ago
  SPA's ruined everything. All the beauty has to be handled manually.
  - ng12 10y ago
    SPA's didn't ruin everything, users ruined everything. Site responsiveness is demonstrably important for almost all user metrics -- conversions, sales, customer experience [1]. Even if a page load is blindingly fast a refresh is still perceived as "slow" from a user perspective. And yet they still expect URLs to maintain some sort of relative functionality. HATEOAS is a great idea for a simple site but not when it's affecting my bottom line. [1] https://www.quora.com/How-do-page-load-times-affect-e-commerce-conversion-rates https://www.quora.com/How-do-page-load-times-affect-e-commer...
    - carsongross 10y ago
      This is the fundamental conflation: SPA != a responsive web app. There were and are other options that don't toss the advantages of the the web architecture and return us to the client-server programing paradigm of the 80s & 90s.
      - ng12 10y ago
        I'm not sure I understand this, is your argument that there are responsive web apps that are not SPAs? I would agree that they exist but are not solving the same problems. Also, what's wrong with the client-side paradigm other than that it's old? The only thing I'm really missing out on is SEO which doesn't matter in a lot of domains.
        carsongross 10y ago
        Yes, there are apps that are very responsive that are not SPAs. They are solving many of the problems traditional web applications have. DHH has written extensively on techniques for building them, and I have written a library for building them as well. There are many problems with the client-side paradigm: security, API churn, we lose Rest/HATEOAS, complexity, etc. That's not to say that the client side paradigm is always the wrong choice, it has its strengths as well, but it is rather to say that making it the default choice, without considering the problem at hand, is foolish.
- wesleytodd 10y ago
  > Anybody can write some HTML with some anchor tags and tie it to some routes declared in a server-side routing file. The back button will work. History will work. Refresh will work. Copy-and-pasting the URL into an email will work. It's so easy that even I can do it. The solution I use[1], and disclaimer also wrote, was targeted directly at server rendered SPA's to follow closely with these ideals. Layers over native anchor tags, just barebones handles the link clicking and uses Express routing which is obviously back end compatible. [1] https://github.com/wesleytodd/nighthawk https://github.com/wesleytodd/nighthawk
  - wesleytodd 10y ago
    Also, forgot to mention, nighthawk also solves the edge cases mentioned toward the end: * ctrl-clicking to open a new tab * shift-clicking to open a new window * alt-clicking * non-left-clicking * target attribute in <a> * mailto: in href
    - nojvek 10y ago
      This is awesome. 8kb is still pretty ridiculous for a routing library. I do like that there is no special integration. A href links just work.
      - wesleytodd 10y ago
        Agreed, but it is still smaller than the competitors. I would love to reduce it even more, but there is very little concern for file size in express' router since it is server side. Also, I believe it can be made smaller with one of the other bundlers. Browserify is not the most size conscious choice, it just happens to be the one I have the most experience with.
jshmrsn 10y ago
If I copy and re-enter a URL generated by pressing buttons in the demo app, I get a page that just says "BAZ". E.g., the URL to the demo's about page: http://www.thinkloop.com/article/state-driven-routing-react-redux-selectors/demo/about http://www.thinkloop.com/article/state-driven-routing-react-...
msoad 10y ago
I'm doing something similar to this with MobX. React Router was too large for my simple routing need.

10 points by thinkloop 10y ago

Routing is complex. There are a lot of disparate pieces that come together to give users the ability to navigate a site. There is the address bar ui element which displays a url string on screen. There is back/forward functionality accessible through buttons, keyboard shortcuts or other input methods. There are <a> links which navigate to new content in various ways. There is url input through the address bar. I appreciate a look into this world, but routing on the web isn't supposed to be very complex. One of the big simplicity wins of the web network architecture was that it was stateless almost everywhere, with hypertext as the engine of application state[1]. Anybody can write some HTML with some anchor tags and tie it to some routes declared in a server-side routing file. The back button will work. History will work. Refresh will work. Copy-and-pasting the URL into an email will work. It's so easy that even I can do it. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS

thinkloop 10y ago
SPA's ruined everything. All the beauty has to be handled manually.
- ng12 10y ago
  SPA's didn't ruin everything, users ruined everything. Site responsiveness is demonstrably important for almost all user metrics -- conversions, sales, customer experience [1]. Even if a page load is blindingly fast a refresh is still perceived as "slow" from a user perspective. And yet they still expect URLs to maintain some sort of relative functionality. HATEOAS is a great idea for a simple site but not when it's affecting my bottom line. [1] https://www.quora.com/How-do-page-load-times-affect-e-commerce-conversion-rates https://www.quora.com/How-do-page-load-times-affect-e-commer...
  - carsongross 10y ago
    This is the fundamental conflation: SPA != a responsive web app. There were and are other options that don't toss the advantages of the the web architecture and return us to the client-server programing paradigm of the 80s & 90s.
    - ng12 10y ago
      I'm not sure I understand this, is your argument that there are responsive web apps that are not SPAs? I would agree that they exist but are not solving the same problems. Also, what's wrong with the client-side paradigm other than that it's old? The only thing I'm really missing out on is SEO which doesn't matter in a lot of domains.
      - carsongross 10y ago
        Yes, there are apps that are very responsive that are not SPAs. They are solving many of the problems traditional web applications have. DHH has written extensively on techniques for building them, and I have written a library for building them as well. There are many problems with the client-side paradigm: security, API churn, we lose Rest/HATEOAS, complexity, etc. That's not to say that the client side paradigm is always the wrong choice, it has its strengths as well, but it is rather to say that making it the default choice, without considering the problem at hand, is foolish.
wesleytodd 10y ago
> Anybody can write some HTML with some anchor tags and tie it to some routes declared in a server-side routing file. The back button will work. History will work. Refresh will work. Copy-and-pasting the URL into an email will work. It's so easy that even I can do it. The solution I use[1], and disclaimer also wrote, was targeted directly at server rendered SPA's to follow closely with these ideals. Layers over native anchor tags, just barebones handles the link clicking and uses Express routing which is obviously back end compatible. [1] https://github.com/wesleytodd/nighthawk https://github.com/wesleytodd/nighthawk
- wesleytodd 10y ago
  Also, forgot to mention, nighthawk also solves the edge cases mentioned toward the end: * ctrl-clicking to open a new tab * shift-clicking to open a new window * alt-clicking * non-left-clicking * target attribute in <a> * mailto: in href
  - nojvek 10y ago
    This is awesome. 8kb is still pretty ridiculous for a routing library. I do like that there is no special integration. A href links just work.
    - wesleytodd 10y ago
      Agreed, but it is still smaller than the competitors. I would love to reduce it even more, but there is very little concern for file size in express' router since it is server side. Also, I believe it can be made smaller with one of the other bundlers. Browserify is not the most size conscious choice, it just happens to be the one I have the most experience with.

jshmrsn 10y ago

If I copy and re-enter a URL generated by pressing buttons in the demo app, I get a page that just says "BAZ". E.g., the URL to the demo's about page: http://www.thinkloop.com/article/state-driven-routing-react-redux-selectors/demo/about http://www.thinkloop.com/article/state-driven-routing-react-...

msoad 10y ago

I'm doing something similar to this with MobX. React Router was too large for my simple routing need.