feat: threads 2.0 #1330
Merged
feat: threads 2.0 #1330
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +33.5 kB (+8.57%) 🔍 Total Size: 425 kB
|
arnautov-anton
force-pushed
the
feat/threads-v2
branch
3 times, most recently
from
4867084
to
6629c1d
Compare
myandrienko
force-pushed
the
feat/threads-v2
branch
from
18f7bd3
to
0e5d673
Compare
myandrienko
reviewed
Aug 13, 2024
arnautov-anton
commented
Aug 21, 2024
myandrienko
previously approved these changes
Aug 29, 2024
arnautov-anton
force-pushed
the
feat/threads-v2
branch
from
4567993
to
a6d69ef
Compare
myandrienko
previously approved these changes
Sep 2, 2024
oliverlaz
previously approved these changes
Sep 2, 2024
myandrienko
approved these changes
Sep 2, 2024
Merged
arnautov-anton
added a commit
to GetStream/stream-chat-react
that referenced
this pull request
Sep 4, 2024
🚂 GetStream/stream-chat-js#1330 This PR adds components for implementing a thread list view: ThreadList and ChatView. It also adds support for reactive state stores, like the ones that handle the thread list logic in the client. ## useStateStore Implements a binding from the reactive state store in the client to React components. ## ThreadList Implements a thread list. The component itself consists mostly of binding to the `ThreadManager` instance in the client. ## Thread The Thread component was modified to optionally use a reactive `Thread` instance from the `ThreadContext`. The component checks if `ThreadContext` is provided, and if so uses the thread instance from that context. Otherwise, it falls back to the `ChannelContext` as usual. Currently, we use `ThreadContext` in the thread list view, where it is provided by the `ChatView.ThreadAdapter` component. Note that even when `ThreadContext` is used, `ChannelContext` also must be provided. Most our components, including the ones used in threads, still expect the channel context to be there. ## ChatView A set of components implementing a simple in-memory router to switch between channel view and thread list view. Using it is totally optional. Most integrations will probably use their own router instead. Still, nice to have something out-of-the-box. ## WithComponents A new way to provide component overrides. Previously we allowed passing component overrides as props to `Channel` component, and then in some nested components as well, although not consistently. `WithComponents` is a new recommended way to provide component overrides, which requires far less prop drilling and nests nicely. --------- Co-authored-by: Matvei Andrienko <m.y.andrienko@outlook.com>
arnautov-anton
added a commit
to GetStream/stream-chat-react
that referenced
this pull request
Sep 4, 2024
🚂 GetStream/stream-chat-js#1330 This PR adds components for implementing a thread list view: ThreadList and ChatView. It also adds support for reactive state stores, like the ones that handle the thread list logic in the client. Implements a binding from the reactive state store in the client to React components. Implements a thread list. The component itself consists mostly of binding to the `ThreadManager` instance in the client. The Thread component was modified to optionally use a reactive `Thread` instance from the `ThreadContext`. The component checks if `ThreadContext` is provided, and if so uses the thread instance from that context. Otherwise, it falls back to the `ChannelContext` as usual. Currently, we use `ThreadContext` in the thread list view, where it is provided by the `ChatView.ThreadAdapter` component. Note that even when `ThreadContext` is used, `ChannelContext` also must be provided. Most our components, including the ones used in threads, still expect the channel context to be there. A set of components implementing a simple in-memory router to switch between channel view and thread list view. Using it is totally optional. Most integrations will probably use their own router instead. Still, nice to have something out-of-the-box. A new way to provide component overrides. Previously we allowed passing component overrides as props to `Channel` component, and then in some nested components as well, although not consistently. `WithComponents` is a new recommended way to provide component overrides, which requires far less prop drilling and nests nicely. --------- Co-authored-by: Matvei Andrienko <m.y.andrienko@outlook.com> BREAKING CHANGE: ComponentContext no longer provides any defaults
arnautov-anton
added a commit
to GetStream/stream-chat-react
that referenced
this pull request
Sep 4, 2024
🚂 GetStream/stream-chat-js#1330 This PR adds components for implementing a thread list view: ThreadList and ChatView. It also adds support for reactive state stores, like the ones that handle the thread list logic in the client. Implements a binding from the reactive state store in the client to React components. Implements a thread list. The component itself consists mostly of binding to the `ThreadManager` instance in the client. The Thread component was modified to optionally use a reactive `Thread` instance from the `ThreadContext`. The component checks if `ThreadContext` is provided, and if so uses the thread instance from that context. Otherwise, it falls back to the `ChannelContext` as usual. Currently, we use `ThreadContext` in the thread list view, where it is provided by the `ChatView.ThreadAdapter` component. Note that even when `ThreadContext` is used, `ChannelContext` also must be provided. Most our components, including the ones used in threads, still expect the channel context to be there. A set of components implementing a simple in-memory router to switch between channel view and thread list view. Using it is totally optional. Most integrations will probably use their own router instead. Still, nice to have something out-of-the-box. A new way to provide component overrides. Previously we allowed passing component overrides as props to `Channel` component, and then in some nested components as well, although not consistently. `WithComponents` is a new recommended way to provide component overrides, which requires far less prop drilling and nests nicely. BREAKING CHANGE: ComponentContext no longer provides any defaults --------- Co-authored-by: Matvei Andrienko <m.y.andrienko@outlook.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds two new classes: ThreadManager and Thread. These classes are designed to be used as "component backends" - the components being ThreadList and Thread respectively. To achieve easy integration with the UI framework, these classes expose
state- a reactive state store you can subscribe to. Ideally, components contain no business logic and just subscribe to relevant parts of the state.StateStore
This is an immutable store you can subscribe to. Get the latest value with
getLatestValue(), update value withnextorpartialNext, subscribe withsubscribeorsubscribeWithSelector.Thread
Thread loads, stores and paginates thread replies. It also keeps track of read states.
For some level of consistency with channel messages pagination indicators, we have a
paginationobject which stores cursors and loading indicators.After calling
registerSubscriptions, Thread instance starts listening to channel events. See a list ofsubscribe...methods to see which exact events we are listening to.Thread can be active or inactive. This is a UI state - an integrator should mark visible/opened threads as active. Active thread immediately marks all the incoming messages as read.
Although backend supports a lot of query options for thread replies, we only support querying latest replies in chronological order, and then paginating through them. If we were to support all query options, we'd have to:
You are not likely to construct a Thread instance by yourself - you get by calling
channel.getThread()instead.ThreadManager
Loads, stores and paginates threads.
ThreadManager does its best to keep the order of threads in a list stable (which is a business requirement for the ThreadList component). So when a reply arrives in a thread which is not currently in a list, we don't load the thread - instead, we add it to the list of "unseen threads". The UI should then prompt user to reload the list if they require so.
Similarly, when a reply arrives in a thread which is already in the list, we don't reorder the list, but set a
isThreadOrderStaleflag.ThreadManager makes sure that all Thread instances it stores are as up-to-date as possible.