[] Added reference-based field filters, client side filtering issue, and… #10489
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
… aligned bulk editor UI with main UI This commit adds field filtering which includes reference filtering, with accompanying test coverage. There is now search, column, and status filtering similarly to main UI. It also fixes a simple model message bug where the UI stated that a field type could not be recognized when the actual condition was the opposite. Simple fix. The FilterMultiselect component was removed, it conflated the status with the column visibility and forced both to act a bit off of intent despite centralizing code. They are now separated and behave in line with their intended design. Client-side filtering was removed. Both numeric searches and multi-status selections relied on loading a 1000 entries which were then filtered client side. It will stop working predictably for larger entries. Customer has some 58k homes so they are easily going to break 1k entries for certain entries. Filtering behavior is now aligned with the main search system with all being the result of CMA paginated queries (you can’t match search numeric fields, but you can search for greater than, etc via field filters…just like OG UI). Testing in general had multiple updates to deal with typescript hinting errors. It worked, but every file was full of typing errors. Fixed now. Testing was failing with some import in forma 36 and phosphorus icons. Added some vite inline dependancies to fix. The UI layout was also updated because of the addition of field filtering. With the addition of field filters here were multiple “filter” elements all over so they needed to be cleaned up: - Consolidated multiple “filter” controls into a unified row around search. They don’t have the full UI functionality but are clustered together now. - Moved column visibility control above the table with a gear icon to match the main UI pattern - Tried to kept overall structure aligned with the core product UI with the exception of the sort which is to theh. It was just floating all by itself after filter consolidation. Got rid of the vertical wiggle, nav and spacer were not taking spacing into consideration.
sfrouse
changed the title
sfrouse
changed the title
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.
[builk-edit-field-filters] ### Add reference-based field filters and align bulk editor UI with main UI
This commit adds field filtering which includes reference filtering, with accompanying test coverage. There is now search, column, and status filtering similarly to main UI.
It also fixes a simple model message bug where the UI stated that a field type could not be recognized when the actual condition was the opposite. Simple fix.
The FilterMultiselect component was removed, it conflated the status with the column visibility and forced both to act a bit off of intent despite centralizing code. They are now separated and behave in line with their intended design.
Client-side filtering was removed. Both numeric searches and multi-status selections relied on loading a 1000 entries which were then filtered client side. It will stop working predictably for larger entries. Customer has some 58k homes so they are easily going to break 1k entries for certain entries. Filtering behavior is now aligned with the main search system with all being the result of CMA paginated queries (you can’t match search numeric fields, but you can search for greater than, etc via field filters…just like OG UI).
Testing in general had multiple updates to deal with typescript hinting errors. It worked, but every file was full of typing errors. Fixed now.
Testing was failing with some import in forma 36 and phosphorus icons. Added some vite inline dependancies to fix.
The UI layout was also updated because of the addition of field filtering. With the addition of field filters here were multiple “filter” elements all over so they needed to be cleaned up:
Got rid of the vertical wiggle, nav and spacer were not taking spacing into consideration.
Purpose
Tri Pointe Homes asked for this specifically. It was demoed to them during the sales process. The client side filtering update was additional because it won't work and with TPH specifically.
Approach
I tried to hew as close to main UI as possible. Main UI also has no client side filtering for instance. I mimicked the field elements and general layout sans nesting the "sort" button next to the search bar...just to regain some height.
Testing steps
Load in various content type entries and test all the various ways that fields can be filtered.
Breaking Changes
shouldn't be
Dependencies and/or References
This will need a design sign off as well. I am talking with Erin Sandoval now.
at this point just reach out to me @scott.rouse
Deployment
I don't think so...