fix: filter data value doesn't match desktop #203
Merged
Conversation
This file contains hidden or 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
Reviewer's GuideAdjusts filter creation/update logic to be more robust and align filter type values with desktop by reordering the FilterType enum and adding guardrails and logging in the Yjs-based filter hooks. Sequence diagram for Yjs filter creation via useAddFiltersequenceDiagram
actor User
participant WebUI
participant useAddFilterHook
participant Logger
participant OperationExecutor
participant YjsView
participant YjsFields
participant YjsFiltersArray
User->>WebUI: Click add filter for fieldId
WebUI->>useAddFilterHook: invoke(fieldId)
useAddFilterHook->>Logger: debug [useAddFilter] Creating filter
alt Missing view or invalid fieldId
useAddFilterHook->>Logger: warn [useAddFilter] Skipping filter creation
useAddFilterHook-->>WebUI: return
else Valid view and fieldId
useAddFilterHook->>useAddFilterHook: generate filterId
useAddFilterHook->>Logger: debug [useAddFilter] Generated filter id
useAddFilterHook->>OperationExecutor: executeOperations(addFilter)
OperationExecutor->>YjsFields: get(fieldId)
alt Field not found
OperationExecutor->>Logger: warn [useAddFilter] Field not found
OperationExecutor-->>useAddFilterHook: return
else Field found
OperationExecutor->>YjsView: get(filters)
alt Filters array missing
OperationExecutor->>Logger: debug [useAddFilter] Creating new filters array
OperationExecutor->>YjsView: set(filters, new YArray)
end
OperationExecutor->>YjsView: get(fieldType)
OperationExecutor->>useAddFilterHook: getDefaultFilterCondition(fieldType)
alt No default condition
OperationExecutor->>Logger: warn [useAddFilter] No default condition
OperationExecutor-->>useAddFilterHook: return
else Default condition found
OperationExecutor->>Logger: debug [useAddFilter] Setting filter data
OperationExecutor->>YjsFiltersArray: create new filter
YjsFiltersArray->>YjsFiltersArray: set id, field_id, condition, content
YjsFiltersArray->>YjsFiltersArray: set filter_type = FilterType.Data
YjsFiltersArray->>YjsFiltersArray: push(filter)
OperationExecutor->>Logger: debug [useAddFilter] Filter created successfully
end
end
end
useAddFilterHook-->>WebUI: filter added
Class diagram for updated filter-related types and hooksclassDiagram
class FilterType {
<<enumeration>>
And = 0
Or = 1
Data = 2
}
class Filter {
+string id
+string field_id
+string condition
+any content
+FilterType filter_type
}
class YjsDatabaseView {
+YDatabaseFilters filters
}
class YDatabaseFilters {
+Filter[] items
+push(filter)
}
class DatabaseYjsHooks {
+useAddFilter() function
+useUpdateFilter() function
}
class Logger {
+debug(message, context)
+warn(message, context)
}
DatabaseYjsHooks --> FilterType : uses
DatabaseYjsHooks --> Filter : creates and updates
DatabaseYjsHooks --> YjsDatabaseView : reads and writes filters
DatabaseYjsHooks --> YDatabaseFilters : appends filters
DatabaseYjsHooks --> Logger : logs guardrails and filter lifecycle
YjsDatabaseView "1" o-- "0..1" YDatabaseFilters : filters
YDatabaseFilters "1" o-- "*" Filter : contains
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes and found some issues that need to be addressed.
- Reordering the
FilterTypeenum values (And/Or/Data) changes their underlying numeric representations and may break existing persisted data or protocol expectations; consider keeping the original numeric mapping and only adjusting usage or adding explicit serialization if needed. - In
useUpdateFilter, the newif (!fieldId) { Log.warn...; return; }guard followed immediately byif (fieldId) { filter.set(...) }is redundant; you can simplify this by removing the second conditional and settingfield_iddirectly after the guard. - The new debug logging in
useAddFilteris fairly verbose (multiple logs per filter creation); consider collapsing some of these into fewer, more informative log lines or gating them behind a higher log level to reduce noise in production logs.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Reordering the `FilterType` enum values (`And/Or/Data`) changes their underlying numeric representations and may break existing persisted data or protocol expectations; consider keeping the original numeric mapping and only adjusting usage or adding explicit serialization if needed.
- In `useUpdateFilter`, the new `if (!fieldId) { Log.warn...; return; }` guard followed immediately by `if (fieldId) { filter.set(...) }` is redundant; you can simplify this by removing the second conditional and setting `field_id` directly after the guard.
- The new debug logging in `useAddFilter` is fairly verbose (multiple logs per filter creation); consider collapsing some of these into fewer, more informative log lines or gating them behind a higher log level to reduce noise in production logs.
## Individual Comments
### Comment 1
<location> `src/application/database-yjs/database.type.ts:45-47` </location>
<code_context>
- Data = 0,
- And = 1,
- Or = 2,
+ And = 0,
+ Or = 1,
+ Data = 2,
}
</code_context>
<issue_to_address>
**issue (bug_risk):** Reordering `FilterType` enum members will change the persisted numeric values and may break existing data.
This reorders the numeric values from `Data=0, And=1, Or=2` to `And=0, Or=1, Data=2`, so existing `filter_type` values stored via `YjsDatabaseKey.filter_type` will be misinterpreted. Either preserve the original numeric assignments while reordering the declarations, or add a migration to update existing persisted values.
</issue_to_address>
### Comment 2
<location> `src/application/database-yjs/dispatch.ts:3603-3610` </location>
<code_context>
return;
}
+ if (!fieldId) {
+ Log.warn('[useUpdateFilter] FieldId is missing');
+ return;
+ }
+
if (fieldId) {
filter.set(YjsDatabaseKey.field_id, fieldId);
}
</code_context>
<issue_to_address>
**suggestion:** The `fieldId` checks in `useUpdateFilter` are redundant and can be simplified.
Because we already return when `!fieldId`, the subsequent `if (fieldId)` is guaranteed to be true and is redundant. You can replace both conditions with a single early return and then call `filter.set` unconditionally:
```ts
if (!fieldId) {
Log.warn('[useUpdateFilter] FieldId is missing');
return;
}
filter.set(YjsDatabaseKey.field_id, fieldId);
```
```suggestion
if (!fieldId) {
Log.warn('[useUpdateFilter] FieldId is missing');
return;
}
filter.set(YjsDatabaseKey.field_id, fieldId);
```
</issue_to_address>
### Comment 3
<location> `src/application/database-yjs/dispatch.ts:3525` </location>
<code_context>
filters.push([filter]);
+
+ Log.debug('[useAddFilter] Filter created successfully', { filterId: id, filter: filter.toJSON() });
},
],
</code_context>
<issue_to_address>
**suggestion (performance):** Logging `filter.toJSON()` on every filter creation may have performance and noise implications.
Converting the Yjs map to JSON and logging the entire filter on each creation can be costly and produce very noisy logs in hot paths. Consider either logging only key identifiers (e.g. `filterId`, `fieldId`, `fieldType`) or wrapping this in a more verbose log level / feature flag to keep diagnostics useful without adding unnecessary overhead.
Suggested implementation:
```typescript
Log.debug('[useAddFilter] Filter created successfully', { filterId: id });
```
If `fieldId`, `fieldType`, or other lightweight identifiers are available in this scope, you may want to extend the logged object, e.g.:
`{ filterId: id, fieldId, fieldType }`
as long as they do not require converting the entire Yjs map to JSON or otherwise performing heavy computations.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+45
to
+47
| And = 0, | ||
| Or = 1, | ||
| Data = 2, |
There was a problem hiding this comment.
issue (bug_risk): Reordering FilterType enum members will change the persisted numeric values and may break existing data.
This reorders the numeric values from Data=0, And=1, Or=2 to And=0, Or=1, Data=2, so existing filter_type values stored via YjsDatabaseKey.filter_type will be misinterpreted. Either preserve the original numeric assignments while reordering the declarations, or add a migration to update existing persisted values.
josue693
pushed a commit
to josue693/AppFlowy-Web
that referenced
this pull request
Dec 21, 2025
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.
Description
Checklist
General
Testing
Feature-Specific
Summary by Sourcery
Align filter type semantics with desktop and harden filter creation and updates with validation and logging.
Enhancements: