-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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: do not export strings constants #56754
Conversation
I know that I shared this opinion before that I don't like much exported strings like that but I also don't hold this opinion too strongly (compared to others :P) so I'm ok with whatever the majority thinks :) |
Size Change: +71 B (0%) Total Size: 1.72 MB
ℹ️ View Unchanged
|
I'm on the fence on this one. Not strong opinion, but lean towards removing them. From the consumer point of view, is it really useful to have them? They are indeed API surface, like the block or redux store names are, tough perhaps it's enough to have them documented. |
OPERATOR_IN, | ||
OPERATOR_NOT_IN, | ||
} from './constants'; | ||
export { VIEW_LAYOUTS } from './constants'; |
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 think what we would need here is function like getViewLayouts
as in the future we could allow registering more? 🤔
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.
Yes, we could follow what we did with the "core/blocks" store I think.
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 think what we would need here is function like getViewLayouts as in the future we could allow registering more? 🤔
Do you mean as a follow-up to substitute VIEW_LAYOUTS
but we still do this PR, correct?
I've left a comment at #56721 (comment) for VIEW_LAYOUTS
:
The VIEWS_LAYOUT is used for two things
- Detect supports, which also can be removed if we go with this API for the list view/preview DataViews: iterate on list view #56746
- Use the icons in the sidebar. What do we do with this one? Export the icons directly or provide a utility such as getIconForViewType( viewType )?
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 could do it in a follow up, yes.
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.
approving regardless of whatever you go with.
Part of #55083
Follow-up to #56721 (comment)
What?
Remove the exported strings from the
dataviews
package.Why?
Each consumer should maintain its own.
How?
Removes the export and creates new constants in the
edit-site
package.Testing Instructions