- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 28 2024
Aug 27 2024
Merge imports
Simplify the logic and add a comment
Move the function
Extract a constant
Remove the method from DatabaseQueryExecutor
Make the method private
Format
Update names
Fix fetching the last message
We don't stop after fetching the first batch. Instead, we're fetching all the batches one by one immediately.
This is caused by the fact that fetching from the DB is too fast. We probably have an existing bug, that wasn't caught, because fetching from keyservers is a lot slower.
Overall it looks ok, but there are a couple of things that should be fixed, so I'm requesting changes.
Aug 26 2024
It is a really good idea to split this diff because it does a couple of unrelated things. Especially, the part about sending notifs requires some discussion and changes, while all the other parts could be accepted.
Aug 23 2024
Make comments consistent
Rebase
Rebase
Extract thick thread types
Extract thick thread types
In D13085#371052, @ashoat wrote:I don't love that we have two separate mechanisms for this. alertStore's purpose is to record when we show various alerts, and help us control how often we show them based on when they're been shown before. That's basically this use case as well. If there are some differences, I would think it would be better to extend alertStore to do what we want here (eg. use useOnFirstLaunchEffect or persist in a similar fashion) rather than building a separate mechanism.
I'm going to resign as I'm heading to vacation starting tomorrow and it doesn't appear that we have the time to do things right here.
Aug 22 2024
Rename
Aug 21 2024
In D13057#370589, @ashoat wrote:In D13057#370275, @tomek wrote:In D13057#370009, @inka wrote:One thing we could do here is add a separate update type for unread status. This way the logic from D13059 that needs getUpdatedThreadInfo would not be needed, and so getUpdatedThreadInfo would not be needed. But this might be too much work.
Yeah, I'm still not sure if it is a good idea. This change would greatly simplify this logic, but has some downsides: introducing a whole new update type would require implementing its spec, which contains e.g. keyserver db layer - and we don't need that, but skipping it would also be weird. If we introduce this new update type, we will need to answer a question as to why we don't introduce similar updates for other props of the thread info... and it seems like we should do that - introduce a new update info that allows updating any property of thread info in isolation. But that might take some time. I don't think it is worth doing now.
I'm confused about this discussion... don't we already have updateTypes.UPDATE_THREAD_READ_STATUS?
In D13064#370575, @ashoat wrote:Ah – the answer to my question is "Because we're using layout animations, rather than animations driven by a SharedValue." While this approach likely works for the NUX project, I suspect it won't work for the more complicated cases we need to support as part of ENG-8149. It's unfortunate that the approach you've chosen means that your work won't be generalizable.
In D13085#370584, @ashoat wrote:Requesting changes because it seems like alertStore can be used here, and I'd rather avoid reimplementing logic when we can share it instead