Open breathe opened 4 years ago
just fyi: react-router v6 tries to merge the best stuff of react-router and @reach/router and can be seen as the successor of @reach/router v1 and react-router v5. See https://reacttraining.com/blog/reach-react-router-future/.
@ryanflorence @mjackson would really appreciate your input on this.
Would now be a decent time to consider migrating from reach to react-router v6, even in alpha?
My understanding is that the alpha refers to missing features rather than possibility of big API changes or particular instability in features already shipped - so I think the main question is, does v6 already cover the more limited featureset of Reach, and the extra stuff still to be added is more advanced stuff?
The reason I'm keen to switch quite soon is because v6 appears to not have issue #51 (example here with it working in v6) which would be really useful.
But as I say, it feels like migrating to v6 in alpha might be reasonably safe at this point for current Reach users even if it perhaps might not be recommended for current react-router v5 users. Would you agree?
Hi David,
Yes, React Router v6 is ready for you to give it a shot. I'm going to move it into beta status this week, which means the API changes have settled down. Anything you could do with reach/router should now be possible in React Router v6.
We have a migration guide from reach/router to React Router v6. Please let us know on GitHub if you think something's missing.
https://github.com/ReactTraining/react-router/blob/dev/docs/advanced-guides/migrating-reach-to-6.md
Good luck!
-- Michael
On Mon, Jun 8, 2020 at 2:33 AM David Nicholas Williams < notifications@github.com> wrote:
@ryanflorence https://github.com/ryanflorence @mjackson https://github.com/mjackson would really appreciate your input on this.
Would now be a decent time to consider migrating from reach to react-router v6, even in alpha?
My understanding is that the alpha refers to missing features rather than possibility of big API changes or particular instability in features already shipped - so I think the main question is, does v6 already cover the more limited featureset of Reach, and the extra stuff still to be added is more advanced stuff?
The reason I'm keep to switch quite soon is because v6 appears to not have issue #51 https://github.com/reach/router/issues/51 example here https://codesandbox.io/s/musing-microservice-3bes2?file=/src/App.js_ which would be really useful.
But as I say, it feels like migrating to v6 in alpha might be reasonably safe at this point for current Reach users even if it perhaps might not be recommended for current react-router v5 users. Would you agree?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/reach/router/issues/354#issuecomment-640489062, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAWVJ3MIUHPHPSMU54WXX3RVSV6PANCNFSM4KQT7FUA .
@mjackson excellent, thanks - here goes!
I saw that react router v6 is in preview and the preview api is now getting described.
I switched to reach awhile back and prefer it to older react routers.
The new react router api looks pretty good tho — wonder what others think and if they plan to switch.
For me the nice things about the new api:
Also I sometimes find myself wanting to access url params from a deeply nested child component that is not directly rendered by a router or is not always directly rendered by a router. This will be possible with useParams right? My notion of the conceptual semantics is something like “climb the render tree, find the first parent component rendered by the router, give me the same value for useParams that you gave that component?“. Is that the right mental model for the semantics?
The behavior of navigate in reach bothers me. I have “multiple apps” like this
/app1/... /app2/...
Where the app to render is decided by a parent router.
Each app then renders its own router and they all use the same sidebar component with a path like
/:foo/*
I can’t use
navigate(‘newfoo/${rest}’)
Within the sidebar component because navigate is relative to the full url rather than the url context of the component that retrieved the navigate() method. I can’t easily use absolute paths in this context either without doing stupid stuff that each app shouldn’t have to do to teach the sidebar component how to identify “I’m rendered By app1 or app2 or ...”
Not 100% sure that react router v6’s navigate method solves this but I hope it does