[allover]

It's not really bananas when you actually start to think of everything 'as components', and consider that 'render' can neatly, declaratively describe behaviour, not just the DOM.

[thatswrong0]

That _is_ how I think about components, but it's still bananas. Render does not neatly describe this behavior because it necessitates setting unnecessary state. That's gross.

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.

[allover]

Then you can use `useHistory` (or `withRouter` if you're not hooks-ready).

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

[Tenemo]

Since you are talking about using Redux, you most definitely can dispatch push actions with libs like connected-react-router or just use the history API directly (for things like replacing state instead of pushing). Most of the redirects I write are inside business logic and I don't like mixing <Redirect /> in there, too.

[jaquers]

> When really all I want to do is in the business function, directly trigger the redirect and maybe some other logic without any indirection.

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.

[interlocutor]

'render' should render, because that's what the function name says. If you're using it for behavior then you're not using it for the intended purpose.

[thatswrong0]

Now that hooks exist, this should definitely be the case. Before, HoCs / components with render prop functions were actually useful for doing some additional not-directly-render related work.

[allover]

You can now use hooks for some things you might previously want a component for, e.g. useFetch instead of <Fetch />, but don't agree "this should definitely be the case". Dogma is never good.

[allover]

Strongly disagree, and 'because the function is called that' is a very poor reason.

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

[uryga]

could you recommend any articles/tutorials that describe this approach some more?

[allover]

This Ryan Florence talk is a great talk that touches on this topic, especially in some of the more creative examples: https://www.youtube.com/watch?v=kp-NOggyz54

[uryga]

thanks!