You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/upgrading/v5.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -267,7 +267,7 @@ A few important things to notice about v6 in this example:
267
267
automatically detect the best route for the current URL. This prevents bugs
268
268
due to manually putting routes in the wrong order in a `<Switch>`
269
269
270
-
You may have also noticed that all `<Route children>` from the v5 app changed to `<Route element>` in v6. Assuming you followed the upgrade steps to v5.1, this should be as simple as moving your route element from the child position to a named `element` prop.
270
+
You may have also noticed that all `<Route children>` from the v5 app changed to `<Route element>` in v6. Assuming you followed the upgrade steps to v5.1, this should be as simple as moving your route element from the child position to a named `element` prop.
271
271
272
272
<!-- (TODO: can we provide a codemod here?) -->
273
273
@@ -887,7 +887,7 @@ This change was made both to follow more closely the convention established by t
887
887
-`useRouteMatch({ sensitive })` is now `useMatch({ caseSensitive })`
888
888
- It returns a match object with a different shape
889
889
890
-
To see the exact API of the new `useMatch` hook and its type declaration, check out our [API Reference](../hooks/use-match).
890
+
To see the exact API of the new `useMatch` hook and its type declaration, check out our [API Reference](../hooks/use-match).
891
891
892
892
<!-- TODO: Show examples for refactoring useRouteMatch -->
0 commit comments