-
Notifications
You must be signed in to change notification settings - Fork 4.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
Dataviews: Add some client side data handling utils #57488
Dataviews: Add some client side data handling utils #57488
Conversation
Size Change: +607 B (0%) Total Size: 1.69 MB
ℹ️ View Unchanged
|
packages/dataviews/src/utils.js
Outdated
* | ||
* @return {Object[]} Sorted items. | ||
*/ | ||
export const sortByTextFields = ( { items, view, fields, textFields } ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why we need the text fields argument, isn't the sorting config part of the "view" object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me it seems the type of sorting is related to the field, but if we have an API prop in fields it will only be used for client side(that's what Tanstack does too - sortingFn). So I don't think we need to add such an API like that for now.. Did you have something different in your mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ideal scenario for me is that the component end up with a single hook abstracting all of this at some point:
// probably a bad name
const { isLoading, data, paginationInfo } = useLocalRequest( allData, view, fields )
separating textFields means that we have to pass an extra argument to such hooks. Isn't the "type" of the field sufficient here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm.. I'm not sure yet if we could use just the type
. For example in templates author
the type is enumeration
and is used for filters and it could be used for inline editing. But for sorting we just want to do it as a text
field.
I think things will become clearer when we advance the other APIs to use the type
in more complex scenarios too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't "enumeration" a special text field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe yes, but I'm not too eager to abstract right now because as I said, I think we will be able to make more informed decisions when we evolve the other APIs too.. While not pretty right now, we just pass an array and will be much simpler to change in the near future.
@@ -229,7 +241,12 @@ export default function DataviewsPatterns() { | |||
], | |||
[ view.type, categoryId ] | |||
); | |||
|
|||
// Reset the page number when the category changes. | |||
useEffect( () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an unrelated fix for a bug that I observed here.
// Reset the page number when the category changes. | ||
useEffect( () => { | ||
if ( previousCategoryId !== categoryId && view.page !== 1 ) { | ||
setView( { ...view, page: 1 } ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, these categories are built as separate pages, so for me we should reset the entire "view" object when changing categories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of disagree here because while what you say it's true, it feels like we have external filters in the sidebar and for example if I have sorted by title, I'd expect the other categories to be sorted too. No strong opinions for now though, I can update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong opinion too. I don't like this effect though and I'm not sure how to avoid it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my mind this is just a filter that we will need to incorporate in the view
object. Current patterns page is WIP and has many more things to think about - refactor/simplify etc.. It's just that is there is a lot of complexity and want to tackle things iteratively.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also close to the "default views" of the pages data views, it's not really clear whether it's filters or just separate default views.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also close to the "default views" of the pages data views, it's not really clear whether it's filters or just separate default views.
The "default views" are just presets, preconfigured settings for the view, so we still need a "category" filter in place.
@@ -252,10 +256,10 @@ export default function DataviewsTemplates() { | |||
[ authors, view.type ] | |||
); | |||
|
|||
const { shownTemplates, paginationInfo } = useMemo( () => { | |||
const { data, paginationInfo } = useMemo( () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this hook become a reusable hook that filters and sorts and everything based on "view", "allData" and "fields"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can explore this separately better because I think we need to advance the filters API more and see how we can abstract it best. Right now there is a lot of specific code regarding the filtering(see author in templates).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't seem specific at all for me. author_text
is just getValue
and the rest is standard. I'm fine if it's explored separately but I think having something like this is going to help us make the right decisions. And we won't need to expose multiple helpers from the dataviews package only a single hook.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course, eventually we shouldn't have much helpers..
What?
Follow up of: #57333
When data handling is done client side there is some code that can be abstracted and reused. In this PR I introduce two of them:
Testing Instructions