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
@@ -130,16 +200,24 @@ Params aren't only useful for passing some data to a new screen, but they can al
130
200
131
201
To achieve this, you can use the `navigate` method, which acts like `goBack` if the screen already exists. You can pass the `params` with `navigate` to pass the data back:
Here, after you press "Done", the home screen's `route.params` will be updated to reflect the post text that you passed in `navigate`.
187
279
188
-
## Passing params to nested navigators
280
+
## Passing params to a nested screen
189
281
190
-
If you have nested navigators, you need to pass params a bit differently. For example, say you have a navigator inside the `Account` screen, and want to pass params to the `Settings` screen inside that navigator. Then you can pass params as following:
282
+
If you have nested navigators, you need to pass params a bit differently. For example, say you have a navigator inside the `More` screen and want to pass params to the `Settings` screen inside that navigator. Then you can pass params as the following:
191
283
192
-
<samp id="params-nested-navigators" />
284
+
```js name="Passing params to nested screen" snack version=7
This looks convenient, and lets you access the user objects with `route.params.user` without any extra work.
383
+
This looks convenient and lets you access the user objects with `route.params.user` without any extra work.
224
384
225
-
However, this is an anti-pattern. Data such as user objects should be in your global store instead of the navigation state. Otherwise you have the same data duplicated in multiple places. This can lead to bugs such as the profile screen showing outdated data even if the user object has changed after navigation.
385
+
However, this is an anti-pattern. Data such as user objects should be in your global store instead of the navigation state. Otherwise, you have the same data duplicated in multiple places. This can lead to bugs such as the profile screen showing outdated data even if the user object has changed after navigation.
226
386
227
387
It also becomes problematic to link to the screen via deep linking or on the Web, since:
228
388
229
389
1. The URL is a representation of the screen, so it also needs to contain the params, i.e. full user object, which can make the URL very long and unreadable
230
-
2. Since the user object is in the URL, it's possible to pass a random user object representing a user which doesn't exist, or has incorrect data in the profile
390
+
2. Since the user object is in the URL, it's possible to pass a random user object representing a user which doesn't exist or has incorrect data in the profile
231
391
3. If the user object isn't passed, or improperly formatted, this could result in crashes as the screen won't know how to handle it
232
392
233
393
A better way is to pass only the ID of the user in params:
0 commit comments