-
-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: fix message list potentially being empty #4556
Conversation
1f23de5
to
3e412ad
Compare
3e412ad
to
cbc5444
Compare
cbc5444
to
ec81292
Compare
store.subscribe
)ec81292
to
4da4970
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me and seems to make sense, although I would prefery to get this approved by @Simon-Laux since I'm not too familiar with the message store behaviour in detail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code looks like it makes sense
...sometimes. And maybe sometimes showing messages from previous chat. I have not been able to confirm whether this fixes an actual bug. But at least in my understanding this fixes a semantic error. The presence of the error is obvious if you make `store.effect.loadChat()` synchronous. So, what could be happening is that `loadChat` finishes _before_ we subscribe to the new store instance, and thus the state never gets updated, at least not until the next store update, which could be e.g. `fetchMoreMessagesTop`.
Currently it appears that `useStore` is not really used with an argument that can change, so this is just a refactor and not a fix. See previous commit (the messagelist.ts change, `setState(store.getState())`).
4da4970
to
bde1567
Compare
...sometimes.
And maybe sometimes showing messages from previous chat.
I have not been able to confirm whether this fixes
an actual bug.
But at least in my understanding this fixes a semantic error.
The presence of the error is obvious if you make
store.effect.loadChat()
synchronous.So, what could be happening is that
loadChat
finishes beforewe subscribe to the new store instance,
and thus the state never gets updated,
at least not until the next store update, which could be e.g.
fetchMoreMessagesTop
.The second commit also appears to be just a refactor.