0439b96eca
This PR implements a new clean parallel code path for handling the filter manipulated in an object filter dropdown. Remember that the object filter dropdown module is the generic, shared module, that must be vertically implemented in those places : view bar filter button, record table column header cell, view bar details filter chip. So here we implement, just for the text filter input (for example a FULL_NAME field type), a new parallel code path logic, that runs on a new state : objectFilterDropdownCurrentRecordFilterState We still update the selectedFilter state, that is very close to the new objectFilterDropdownCurrentRecordFilterState, but in order to be cautious, and allow us to refactor incrementally, we implement a new parallel code path and let the rest run on selectedFilterState for now. The new way of working with the filter in the object filter dropdown, includes smaller and more specific hooks : - useApplyObjectFilterDropdownFilterValue instead of applyRecordFilter which API generates a lot of tech debt - useObjectFilterDropdownFilterValue to get the current value (might be later removed if too thin) - useUpsertObjectFilterDropdownCurrentFilter, to abstract a bit some duplicated logic in useApplyObjectFilterDropdownFilterValue - useCreateRecordFilterFromObjectFilterDropdownCurrentStates which differs from the existing useCreateEmptyRecordFilterFromFieldMetadataItem in that it uses the current states instead of creating an empty filter with default values. Those two logics are still very confusing and duplicated everywhere, creating specific hooks makes it clear now. This PR shouldn't cause any change in the behavior of the filtering feature. Fixes https://github.com/twentyhq/core-team-issues/issues/717
Run yarn dev while server running on port 3000