Shorten what should be in params docs

Author: satya164

versioned_docs/version-6.x/params.md

@@ -181,9 +181,9 @@ See [Nesting navigators](nesting-navigators.md) for more details on nesting.
 
 ## What should be in params
 
-It's important to understand what kind of data should be in params. Params are like options for a screen. They should only contain information to configure what's displayed in the screen. Avoid passing the full data which will be displayed on the screen itself (e.g. pass a user id instead of user object). Also avoid passing data which is used by multiple screens, such data should be in a global store.
+Params are essentially options for a screen. They should contain the minimal data required to show a screen, nothing more. If the data is used by multiple screens, it should be in a global store or global cache. Params is not designed for state management.
 
-You can also think of the route object like a URL. If your screen had a URL, what should be in the URL? Params shouldn't contain data that you think should not be in the URL. This often means that you should keep as little data as possible needed to determine what the screen is. Think of visiting a shopping website, when you are seeing product listings, the URL usually contains category name, type of sort, any filters etc., it doesn't contain the actual list of products displayed on the screen.
+You can think of the route object as a URL. If your screen had a URL, what should be in the URL? The same principles apply to params. Think of visiting a shopping website; when you see product listings, the URL usually contains category name, type of sort, any filters etc., not the actual list of products displayed on the screen.
 
 For example, say if you have a `Profile` screen. When navigating to it, you might be tempted to pass the user object in the params:
 
@@ -199,15 +199,17 @@ navigation.navigate('Profile', {
 });
 ```
 
-This looks convenient, and lets you access the user objects with `route.params.user` without any extra work.
+This looks convenient and lets you access the user objects with `route.params.user` without any extra work.
 
-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.
+However, this is an anti-pattern. There are many reasons why this is a bad idea:
 
-It also becomes problematic to link to the screen via deep linking or on the Web, since:
+- The same data is 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.
+- Each screen that navigates to the `Profile` screen now needs to know how to fetch the user object - which increases the complexity of the code.
+- URLs to the screen (browser URL on the web, or deep links on native) will contain the user object. This is problematic:
 
-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
-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
-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
+  1. Since the user object is in the URL, it's possible to pass a random user object representing a user that doesn't exist or has incorrect data in the profile.
+  2. 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.
+  3. The URL can become very long and unreadable.
 
 A better way is to pass only the ID of the user in params:
 

versioned_docs/version-7.x/params.md

@@ -375,9 +375,9 @@ See [Nesting navigators](nesting-navigators.md) for more details on nesting.
 
 ## What should be in params
 
-It's important to understand what kind of data should be in params. Params are like options for a screen. They should only contain information to configure what's displayed in the screen. Avoid passing the full data which will be displayed on the screen itself (e.g. pass a user id instead of user object). Also avoid passing data which is used by multiple screens, such data should be in a global store.
+Params are essentially options for a screen. They should contain the minimal data required to show a screen, nothing more. If the data is used by multiple screens, it should be in a global store or global cache. Params is not designed for state management.
 
-You can also think of the route object like a URL. If your screen had a URL, what should be in the URL? Params shouldn't contain data that you think should not be in the URL. This often means that you should keep as little data as possible needed to determine what the screen is. Think of visiting a shopping website, when you are seeing product listings, the URL usually contains category name, type of sort, any filters etc., it doesn't contain the actual list of products displayed on the screen.
+You can think of the route object as a URL. If your screen had a URL, what should be in the URL? The same principles apply to params. Think of visiting a shopping website; when you see product listings, the URL usually contains category name, type of sort, any filters etc., not the actual list of products displayed on the screen.
 
 For example, say if you have a `Profile` screen. When navigating to it, you might be tempted to pass the user object in the params:
 
@@ -395,13 +395,15 @@ navigation.navigate('Profile', {
 
 This looks convenient and lets you access the user objects with `route.params.user` without any extra work.
 
-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.
+However, this is an anti-pattern. There are many reasons why this is a bad idea:
 
-It also becomes problematic to link to the screen via deep linking or on the Web, since:
+- The same data is 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.
+- Each screen that navigates to the `Profile` screen now needs to know how to fetch the user object - which increases the complexity of the code.
+- URLs to the screen (browser URL on the web, or deep links on native) will contain the user object. This is problematic:
 
-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
-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
-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
+  1. Since the user object is in the URL, it's possible to pass a random user object representing a user that doesn't exist or has incorrect data in the profile.
+  2. 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.
+  3. The URL can become very long and unreadable.
 
 A better way is to pass only the ID of the user in params: