I've seen Redux described as "a pattern with really good documentation", and there's some truth to that. On the other hand, we've put a _lot_ of work into React-Redux in particular [2] to make sure it's optimized and works well with React.

As a side note, we have a new official Redux Toolkit package [3] that is our recommended approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.

[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[1] https://gist.github.com/gaearon/ffd88b0e4f00b22c3159

[2] https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

[3] https://redux-toolkit.js.org

Routers can be (and should be, IMO) written to be independent of UI component libraries such as React and webcomponents. See an example here: https://github.com/Rajeev-K/mvc-router You can use it with React---and in some ways it works better than react-router.

Usually when I need to trigger a redirect, I'm in some business-level function. So to redirect this way, I would need to set some state in my store, re-render, then hit the conditional, which would redirect, probably unset that state, and then probably trigger some additional business logic.

When really all I want to do is in the business function, directly trigger the redirect and maybe some other logic without any indirection. redux-react-router exists, but it's API is still obtuse compared to something like redux-first-router.

I somewhat agree that the <Redirect /> component is not actually that useful, it's only useful in very simple cases like "based on one route plus conditional redirect to another", e.g.:

    <Route path="/">
      {usersPreviousShoppingGender === "women" ? (
        <Redirect to="/women" />
      ) : (
        ...
      )}
      ...
    </Route>
    <Route path="/women">

Heh, didn't see this comment before I left a novel up the tree. Seems we have similar ideas about state management.

I think the default RR API is straight React, and that is by design.

You're not using React to its full potential if you think like this.

I mean, I see why it's intuitively unappealing to you, but there are perfectly good reasons for the design.

I'm not sure I see how obvious it is that a <Redirect/> is wrong. But that's fine, I take your point that it's not particularly intuitive.

I'm of the opinion that routing, in general, is a function of application state - and I like to manage my application state with Redux - so I will often also mix in connected-react-router [1]. This lets you do navigation w/ an imperative API [2].

[0] https://github.com/ReactTraining/react-router/tree/master/pa...

[1] https://github.com/supasate/connected-react-router

[2] https://github.com/supasate/connected-react-router/blob/mast...

That's one alternative. Another is not to try implementing behaviour that has nothing to do with rendering using a rendering library in the first place.

A horrible amount of accidental complexity has been created in the React ecosystem when people have tried to use it like a full framework. If all you have is a hammer, maybe it's time to consider using other tools as well.

    𝚖𝚢-𝚛𝚘𝚞𝚝𝚎𝚛
      𝚖𝚢-𝚛𝚘𝚞𝚝𝚎(𝚙𝚊𝚝𝚝𝚎𝚛𝚗="/𝚑𝚘𝚖𝚎")
        // 𝚜𝚘𝚖𝚎 𝚑𝚘𝚖𝚎 𝚙𝚊𝚐𝚎
      𝚖𝚢-𝚛𝚘𝚞𝚝𝚎(𝚙𝚊𝚝𝚝𝚎𝚛𝚗="/𝚗𝚎𝚠𝚜")
        // 𝚜𝚘𝚖𝚎 𝚗𝚎𝚠𝚜 𝚙𝚊𝚐𝚎

edit: unidecoded:

  my-router
        my-route(pattern="/home")
        // some home page
        my-route(pattern="/news")
        // some news page

In fact, most web applications only need this 200-line library: https://github.com/wisercoder/uibuilder

React started out as a simple library, but it is getting more and more complicated (see concurrent mode). 90% of applications don't benefit from React's complexity. This tiny lib has the same templating technology as React, but none of the complexity.

I guess that's complicated but I can see even basic apps benefiting from it.