Is your feature request related to a problem? Please describe.
Given a large number of entries in a collection that have different taxonomies (like blog posts or products) it can become unmanageable to quickly find an entry belonging to a certain taxonomy or matching a criterion.
Describe the solution you'd like
Ideally the end user should be able to filter the displayed entries of a collection using a filter dropdown.
The filters should come in two flavors.
Describe alternatives you've considered
Additional context
In this context it is probably also useful to spice up the filter framework to allow for more precise filtering, such as checking if value is in / not in a predefined list, if a number / date is <,<=,>,>=, etc. This probably warrants it's own issue.
Additionally it would habe to be defined for custom fields how they can contribute by providing their available options.
@hanneskuettner can I work on this feature?
@BA1RY I realised you mentioned @hanneskuettner so I unassigned you until we get a response.
There is also https://github.com/netlify/netlify-cms/issues/3614 which is related.
@BA1RY sure thing. I haven't started yet.
Is the feature proposal clear enough or should we first define a bit more of the behavior and actual syntax / use cases before work is done in the wrong direction @erezrokah?
I feel like the scope isn't perfectly well defined. I don't have time right now to flush it out. I could give it a look tomorrow.
@erezrokah can i work on it ?
- Fixed filters that have preconfigured conditions and apply across the whole collection, similar to how the filter attribute works. They can have a label and would be bundled in a single filter menu like so:
@hanneskuettner I think that the quoted part can be a first iteration. That is a fixed filterableFields
config with a field name and condition to filter by (and possibly a display label for the filter). As for the second part it will require some thought like you said as it would be ideal to automatically infer the filters content. How does that sound?
@BA1RY Are you good with just doing the first part? I think that will allow us to gain more insights into this feature.
@MohamedBechir thanks but I think the issue is already taken.
@erezrokah Yeah, I can do that. Also, how would you want me to proceed in implementing that feature?
@BA1RY I think you can use the current sort functionality as a reference. I would start first with the UI since it helps figuring out which information needs to be specified in the configuration.
@erezrokah Understood. Also, shall I create a new component called DropdownCheckedItem in 'netlify-cms-ui-default' to accomodate checkbox in the dropdown?
Sounds good @BA1RY
That's actually great - this is the point we should think on how the config would look like.
For sort, we infer the default sortable fields here https://github.com/netlify/netlify-cms/blob/a9d0699a82a25d79dd99af4f1ed9643ce7bba220/packages/netlify-cms-core/src/reducers/collections.ts#L376 and use the fields labels for display. This can be overridable in the config.
Since there is already a filter configuration I would use that:
https://www.netlifycms.org/docs/add-to-your-site/#filter
But add support for an array of filters, then use the field label and filter value for display.
I think adding it to the filter property is confusing and not actually what we want.
The filter property is used for filtering the whole collection and only displaying those entries and not for defining user defined, visual filters.
Reusing this property and modifying it is potentially a breaking change since there are projects which might use this for only showing a certain subset of entries of a collection. With reusing the filter property a user could now disable the filter and potentially see entries which are not intended for that collection. Is it understandable what I'm getting at?
I suggest something like adding a view_filters
option which is applied on the entries of a collection after the filter
property.
These should be an array that allows a filter field (potentially nested fields), a label and a filter condition.
For the filter condition I'm envisioning something that should be ported to be used in the collection filter
as well. Allowing various filter conditions, not only value
(which is basically an equal
) as it is right now.
I could see the following keys that can be used in the filter object:
eq
(equal to the value)lt
/lte
and gt
/gte
(<
,<=
,>
,>=
for ordinal values like number and dates)in
/ not_in
(value is (not) contained in a list)An entry in the view_filters
property could look something like this:
view_filters:
- label: "Peter's and Arnold's Posts"
field: author
in: ["Peter", "Arnold"]
Why might also want to an enabled
property for enabling or disabling a filter by default.
Is it understandable what I'm getting at?
Oh I get it, you're right - filter property should remain hidden.
I suggest something like adding a
view_filters
option which is applied on the entries of a collection _after_ thefilter
property.
Good suggestion.
@erezrokah Any changes regarding implementaiton of filter functionality?
Also I would add that we could allow multiple filter conditions to for example allow combinations of in
and lt
.
Maybe also a regex pattern
condition.
@erezrokah I was busy the last few days as I had work from college. So I wasn't able to do much. Will work on it from today.
I'm facing another problem. After I start the development server using yarn start
command, my system freezes everytime I make a change and the hot reloading happens. It consumes about 2-5 minutes on average. Is there workaround to reduce this reloading time?
@erezrokah how will this all be reconciled in the v3-ui-redesign
branch as we are using new components? Should we be adding this functionality to that branch as well in parallel?
Good point @austincondiff, I think I'll create an issue with the features diff then we can open sub issues based on that.
Hey @erezrokah could you reopen this since only part 1 has been implemented so far?
The dynamic filter (which is much more powerful an still warranted imho) is still open for discussion.
Sure thing, got too eager with closing issues 馃う
Something that might be a good addition to this is allowing certain filters to be applied by default, perhaps by allowing:
view_filters:
- label: "Example label"
field: "example_field"
pattern: "value1|value2"
default: true