3 ms·
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.
by thatswrong0 7y ago
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.
- jaquers 7y ago> 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.
- Tenemo 7y agoSince 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.
- allover 7y agoThen 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">