facebook
diff --git a/Collapse file
‎website/docs/guided-tour/list-data/advanced-pagination.md‎
Copy file name to clipboardExpand all lines: website/docs/guided-tour/list-data/advanced-pagination.md
-43Lines changed: 0 additions & 43 deletions
Display the source diff
Display the rich diff b/Collapse file
‎website/docs/guided-tour/list-data/advanced-pagination.md‎
Copy file name to clipboardExpand all lines: website/docs/guided-tour/list-data/advanced-pagination.md
-43Lines changed: 0 additions & 43 deletions
Display the source diff
Display the rich diff
diff --git a/Collapse file
‎website/docs/guided-tour/updating-data/updating-connections.md‎
Copy file name to clipboardExpand all lines: website/docs/guided-tour/updating-data/updating-connections.md
+2-13Lines changed: 2 additions & 13 deletions
Display the source diff
Display the rich diff b/Collapse file
‎website/docs/guided-tour/updating-data/updating-connections.md‎
Copy file name to clipboardExpand all lines: website/docs/guided-tour/updating-data/updating-connections.md
+2-13Lines changed: 2 additions & 13 deletions
Display the source diff
Display the rich diff
@@ -155,46 +155,3 @@ function FriendsListComponent(props: Props) {
 
 * The APIs for both *"forward"* and *"backward"* are exactly the same, they're only named differently. When paginating forward, then the  `after` and `first` connection arguments will be used, when paginating backward, the `before` and `last` connection arguments will be used.
 * Note that the primitives for both *"forward"* and *"backward"* pagination are exposed from a single call to `usePaginationFragment`, so both *"forward"* and *"backward"* pagination can be performed simultaneously in the same component.
-
-
-
-## Custom Connection State
-
-By default, when using `usePaginationFragment` and `@connection`, Relay will *append* new pages of items to the connection when paginating *"forward",* and *prepend* new pages of items when paginating *"backward"*. This means that your component will always render the *full* connection, with *all* of the items that have been accumulated so far via pagination, and/or items that have been added or removed via mutations or subscriptions.
-
-However, it is possible that you'd need different behavior for how to merge and accumulate pagination results (or other updates to the connection), and/or derive local component state from changes to the connection. Some examples of this might be:
-
-* Keeping track of different *visible* slices or windows of the connection.
-* Visually separating each *page* of items. This requires knowledge of the exact set of items inside each page that has been fetched.
-* Displaying different ends of the same connection simultaneously, while keeping track of the "gaps" between them, and being able to merge results when preforming pagination between the gaps. For example, imagine rendering a list of comments where the oldest comments are displayed at the top, then a "gap" that can be interacted with to paginate, and then a section at the bottom which shows the most recent comments that have been added by the user or by real-time subscriptions.
-
-
-To address these more complex use cases, Relay is still working on a solution:
-
-
-> TBD
-
-
-
-
-## Refreshing connections
-
-> TBD
-
-
-
-
-## Prefetching Pages of a Connection
-
-> TBD
-
-
-
-
-## Rendering One Page of Items at a Time
-
-> TBD
-
-
-
-<DocsRating />
@@ -553,11 +553,9 @@ function updater(store: RecordSourceSelectorProxy) {
 
 
 
-_Managing connections with many filters:_
+### Managing connections with many filters
 
-As you can see, just adding a few filters to a connection can make the complexity and number of connection records that need to be managed explode. In order to more easily manage this, Relay provides 2 strategies:
-
-1) Specify exactly *which* filters should be used as connection identifiers.
+As you can see, just adding a few filters to a connection can make the complexity and number of connection records that need to be managed explode. In order to more easily manage this, Relay allows you to specify exactly *which* filters should be used as connection identifiers.
 
 By default, *all* non-pagination filters will be used as part of the connection identifier. However, when declaring a `@connection`, you can specify the exact set of filters to use for connection identity:
 
@@ -591,13 +589,4 @@ const storyFragment = graphql`
 * Conceptually, this means that we're specifying which arguments affect the output of the connection from the server, or in other words, which arguments are *actually* *filters*. If one of the connection arguments doesn't actually change the set of items that are returned from the server, or their ordering, then it isn't really a filter on the connection, and we don't need to identify the connection differently when that value changes. In our example, changing the `language` of the comments we request doesn't change the set of comments that are returned by the connection, so it is safe to exclude it from `filters`.
 * This can also be useful if we know that any of the connection arguments will never change in our app, in which case it would also be safe to exclude from `filters`.
 
-
-
-2) An easier API alternative to manage multiple connections with multiple filter values is still pending
-
-
-> TBD
-
-
-
 <DocsRating />