Filter works incorrectly if fields are splitted by several log actions
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 747
- Forks
- 49
- PR merge metrics
- No merged PRs in 30d
Description
Hello, I've debugged this issue https://github.com/logux/examples/issues/21 and found that there is a bug in the filters.
I can reproduce it with a simple test:
it('filter works correctly if sent not all fields', async () => {
let client = new TestClient('10')
await client.connect()
client.log.keepActions()
let posts = createFilter(client, Post, { authorId: '1'})
let unbind = posts.listen(() => {})
await allTasks()
await client.server.sendAll({ channel: 'posts/1', type: 'logux/subscribed' })
await client.server.sendAll({
fields: { title: 'A' },
id: '1',
type: 'posts/created'
})
await client.server.sendAll({
fields: { authorId: '1' },
id: '1',
type: 'posts/changed'
})
await allTasks()
expect(ensureLoaded(posts.get()).list).toEqual([
{ id: '1', isLoading: false, title: 'A', authorId: '1' },
])
unbind()
})
I want to fix it but I need some information on how that should work.
As I understand we need to accumulate log actions for an object until we receive the fields required for a filter.
What is the best way to achieve this?
Version: 0.21.1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start from the createFilter entry point and the TestClient reproduction shown in the issue. Run the test with the posts/created and posts/changed actions split across log entries, then trace how filter state handles each action. Done means the accumulated fields produce one loaded post matching the expected list.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100