-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(list-page): add filtering options by timestamp #8965
base: main
Are you sure you want to change the base?
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8000d82:
|
do you plan to add time field as well? |
@gautamsi I'm not a maintainer of the repo, I don't even know if this PR will be accepted. I'm not sure what you mean by time fields? This works for dates / timestamps |
@gautamsi Sorry missed that you were a member haha. Still not sure of what you mean, to be honest I built this because we needed it but I can add support for other fields I guess. |
Btw I didn't see any prettier /formatter config, any suggestions? |
I am a member as part of restricted preview group long time ago, I have not much permission :( I meant |
@gautamsi Okay np. I think time would be a bit more challenging to implement, is it something you would use rather than filtering by date? |
I had to do this for a customer, I took different approach. in v5 the timestamp field was using |
I see… I think in our use case precise times are not really useful since we might be dealing with more long term objects |
If you are not covering general use case I am not sure if this PR will be any useful, This can be for reference for others to implement such custom view. |
Yes sure took me a bit of time to understand how to implement this and maybe others will benefit from it. What I meant was I need this feature so I built it in hope that it will be merged and that I don't have to maintain a fork etc. |
you do not have to maintain a fork, you can use custom view which will replace the current filters, we have implemented several other type of filters with custom views for our clients |
Oh so good, do you know where I can find some docs? this look empty: |
@dcousens sorry for this pings, same question with this PR. Is this something you are inserted in / intend to merge? |
@dcousens curious to have your reaction on this as well, when you have some time |
As this is a timestamp, we should show a complete timestamp. As for suitability, I'm not against only showing a date picker for now. I think I agree with @gautamsi that https://www.npmjs.com/package/chrono-node might be a better option; as if you only need date precision, why not use the |
For timestamps I think we could do a date picker first and another PR for timestamps if needed?
I'm okay to update this PR to use the package but tbh I'm not quite sure I understand how this would look like. I mean what does the user input visually looks like if we were to use chrono-node?
I think with time we have moved away from calendarDay, finding them hard to use for broader usage in growing applications. Timestamps have shown to be more versatiles / flexible. But maybe it's a pre-conceived idea and time to reconsider. Are calendarDay filterable in a search page? |
Hi @dcousens sorry to bother you! What are the blocking points for this PR? It's something we'd like to have in keystone |
Create a BlockDatePicker component (Calendar not wrapped in popover) to prevent issues with multiple nested popover (wrong behaviour of on click outside)
@dcousens rebased main to keep the branch up to date |
Any news on this pr ? |
Hi! I find this PR helpful, how do implement these changes in keystone project? here is my package json for reference
|
Currently in the list page we can't filter by dates.
To prevent issues with multiple nested popover (wrong behaviour of on click outside) I had to create a BlockDatePicker component (Calendar not wrapped in popover)
There might be a better way but it was the easiest non-breaking idea.