-
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
Export store from the edit-site package #51986
Conversation
Size Change: +6 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
Flaky tests detected in 7bd48ed. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5392095334
|
I can't think of a reason why we should't export the edit site store, but I might be missing some context maybe? --cc @WordPress/gutenberg-core @youknowriad. Just mentioning that the specific example in the description though( |
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 widgets editor does not export its store either.
Doesn't exporting the store of the editor feel like we're exporting the jungle in the bannana gorila jungle idea?
I know the post editor exports its store, but at a high level it seems that if you need something the site editor does in some context that thing should probably be then in a more foundational package, or the editor should selectively export that if it's a public API?
Editors are the final result of all composition. It's fine to export things that allow programatically manipulating the editor, but all the store maybe it's too much?
This is a developer experience issue. There are many examples that import the store and pass it to If we need to create documentation that specifies which packages support the importing of the store, then we should move all examples to hard code the string name of the store, otherwise this is just another weird gotcha that developers will have to fight against while trying to adopt. |
Even if the store is not exported extenders can still use it using a string, no? Therefore I think may as well export the store since it doesn't make any practical difference to what's available and makes build tooling work nicer. |
Yeah, @noisysocks is right :) |
thanks for the approval here @noisysocks. There will be other PRs incoming to address this issue in other packages as well. I'll be sure to ping you on them ) |
The main reason for me is that people are going to think that it's ok to Maybe we have a lint rule for it though I don't know. |
But I think the way to discourage having |
No it's not within our code base. -- |
Oh gotcha. Yeah perhaps a gutenberg lint rule is best then. |
What?
While working on adding examples to the edit-site package as part of #42125, I discovered that the package does not export its
store
which does not allow for importing it for use with useSelect/useDispatch like other stores.Why?
Most of the examples import the store directly from the package and the expectation should be the same for this package.
How?
Exporting the store from the main
index.js
file.Testing Instructions
Add the following code into a block and confirm that there is an console error:
Build this branch locally and confirm that the issue is fixed