Comments (25)
Closing the issue as the decision was taken: We'll use wp_store
for PHP and store
in JavaScript.
We can always reconsider it and reopen the issue if needed.
from block-interactivity-experiments.
I like the store()
name! My second-place suggestion was to call it createStore()
but I agree with @luisherranz that it adds to the camelcase vs snakecase confusion.
There's some prior art for naming in this space:
- Solid uses the
create*
naming:createStore()
,createEffect()
- Vue's Composition API went with single-word names that are somewhat similar. Their
reactive()
is ourstore()
, theref()
is basicallysignal()
, etc.
from block-interactivity-experiments.
I like store()
as well. I agree that keeping it with just one word would be better. Anyway, if we finally have to add something more verbose, I believe it won't be a big issue. It is something we are already doing. For example, registerBlockType
vs register_block_type
.
from block-interactivity-experiments.
I also think wp_store
in php context is way too generic and hard to relate to what it does. Is it about saving things to the database? Is it about commerce? It just feels rather inscrutable.
from block-interactivity-experiments.
Do tell ๐
I really can't say too much! Not because I don't want to, it's just that the ideas are not yet well-formed. Also don't want to derail this thread ๐.
There are some ideas from over a year ago in WordPress/gutenberg#38224 exploring compiling a template format to both JS and PHP.
More recently, some of us working in this repo have talked about building a similar template compiler where the data-wp-*
directives would be the "compile target". There is not even a prototype of this, and it might never even happen. How would it work exactly? We also have no idea yet ๐ .
If you want to talk about it some more, let's open a new issue, and let's cc @luisherranz, who might have some more thoughts on this front.
from block-interactivity-experiments.
I think wp_block_store
or wp_block_state
could work well.
from block-interactivity-experiments.
What about state? That's what is being stored here, right?
wp_init_block_state()
wp_set_state()
wp_interactivity_state()
For me, speaking of state feels more clear than store.
The store, however, can contain other properties, like
selectors
:
I would highly suggest to use the word store
. It's already the standard naming convention for state/store mechanisms like redux, vuex, etc.
No need to reinvent the wheel. Developers will already know what this means which will eliminate the cognitive load of learning new naming conventions.
from block-interactivity-experiments.
I agree with Michal and Marioโmaybe we are a bit biased with store()
, though, as that's the name we're most used to. ๐
from block-interactivity-experiments.
Let's use store()
for now, then. Thanks, folks.
from block-interactivity-experiments.
@gziolo mentioned to me that store
is too general and can conflict with plugins. We would need to use wp_store
or something similar.
I'm reopening so we can discuss again.
from block-interactivity-experiments.
@gziolo mentioned to me that
store
is too general and can conflict with plugins. We would need to usewp_store
or something similar.
It only applies to PHP. On the JavaScript side, devs import store
from the npm package, so it's namespaced and won't ever become an issue.
Technically speaking, store()
could be used as the name for the function, as it isn't used in WordPress core. The best way is to check Developer Resources page. I'm not aware of exact naming conventions enforced today, but many recently added functions tend to get prefixed with wp_
because WordPress core didn't adopt namespaces.
from block-interactivity-experiments.
Pardon my ignorance, but is the convention that plugins must not use function names that start with wp_
, hence wp_store
is safe, but they can use function names that don't have a prefix, hence store
is unsafe? Is that the case?
Is there any other resource about function names other than what is in the PHP Coding Standards?
from block-interactivity-experiments.
Pardon my ignorance, but is the convention that plugins must not use function names that start with
wp_
, hencewp_store
is safe, but they can use function names that don't have a prefix, hencestore
is unsafe? Is that the case?
Yes, I know how it sounds, and your response is spot on.
Is there any other resource about function names other than what is in the PHP Coding Standards?
I think it's becoming "safer" when plugin developers follow Best Practice: Prefix Everything. The best approach would be to ask on WordPress Slack in the #core channel.
from block-interactivity-experiments.
So, what do you think about wp_store
for PHP and store
(import { store }ย from ...
) in JavaScript?
from block-interactivity-experiments.
So, what do you think about
wp_store
for PHP andstore
(import { store }ย from ...
) in JavaScript?
It made me think that someone had to make similar decisions when bringing WP Hooks and i18n helpers to JavaScript. @adamsilverstein, or @swissspidy do you have any recommendations?
I see that for hooks, API looks the same but follows language-specific coding styles, in effect:
doAction
vsdo_action
addAction
vsadd_action
applyFilters
vsapply_filters
addFilter
vsadd_filter
For i18n it seems like it was possible to achieve one to one match for equivalent methods.
from block-interactivity-experiments.
Not sure if these are good examples, because there we ported already very established PHP functions to JS, not vice-versa. Here it's a new thing for both sides.
My 2 cents after a quick glance:
"store" is a very generic term and without additional context a (new) developer would probably not understand what a store()
or wp_store()
function does in PHP.
For JS it doesn't seem a big issue as you import from the package, which gives you that additional context. Keeping store()
there sounds reasonable.
But for PHP, could it perhaps be named more verbose, e.g. wp_block_store()
or something?
from block-interactivity-experiments.
Thanks, Pascal ๐
I think it makes sense to find something more verbose. But until we do, let's switch from store
to wp_store
to adapt to this convention:
[...] plugins must not use function names that start with
wp_
, hencewp_store
is safe, but they can use function names that don't have a prefix, hencestore
is unsafe.
from block-interactivity-experiments.
Reopening in light of the comment from Matias above.
Suggestions to brainstorm this some more:
wp_interactivity_store
wp_data_store
wp_create_interactive_store
(that might imply adding thecreate_
prefix to the JS function.- Some other combination of
wp_
,data
,store
&interactivity
?
from block-interactivity-experiments.
What about state
? That's what is being stored here, right?
wp_init_block_state()
wp_set_state()
wp_interactivity_state()
For me, speaking of state
feels more clear than store
.
from block-interactivity-experiments.
What about state? That's what is being stored here, right?
Yes, that's true at the moment, and I like those suggestions! ๐
That said, there are some (still very distant) ideas of serializing more than just the state. Whatever name we come up with, I'd like to plan for that eventuality. So, either we have to be fine with potentially creating a new function in the future (if we end up serializing more than just the state), or we find a more flexible name now.
from block-interactivity-experiments.
Total new voice here, but interactive
is a really long prefix, and this really is intended to be like the way (in my mind) to do block based UI, what about wp_ui_state
? Is the wp_ui
prefix used by any other system in WordPress?
from block-interactivity-experiments.
there are some (still very distant) ideas of serializing more than just the state
Do tell ๐
from block-interactivity-experiments.
@luisherranz, who might have some more thoughts on this front
I don't think we need to serialize anything else than state
. The state
property is the source of truth and everything else should be derived from it.
The store, however, can contain other properties, like selectors
:
$counter = 0;
wp_store( array(
'state' => array(
'myPlugin' => array(
'counter' => $counter,
),
),
'selectors' => array(
'myPlugin' => array(
'double' => $counter * 2,
),
),
) );
store({
state: {
myPlugin: {
counter: 0, // Not really needed if you have declared it in the server
},
},
selectors: {
myPlugin: {
double: ({ state }) => state.myPlugin.counter * 2,
},
},
});
Whether there's a fixed number of properties (state
, selectors
, actions
, effects
) or not, it's up for discussion. I'm inclined to say people can add whatever they want, and only state
is special (serialized and reactive).
I reckon store
may not be a straightforward name, but I'd rather not refer to it using state
because it includes the state
property and maybe others (selectors
) so I think it could also be confusing.
wp_xxx_state( array(
'state' => array(
'myPlugin' => array(
'counter' => $counter,
),
),
'selectors' => array(
'myPlugin' => array(
'double' => $counter * 2,
),
),
) );
from block-interactivity-experiments.
I reckon store may not be a straightforward name, but I'd rather not refer to it using state because it includes the state property and maybe others (selectors) so I think it could also be confusing.
One more note here, the state is global, so the name would end up somewhere close to wp_blocks_state
. It sounds really weird when you read it without underscores ๐คฃ
from block-interactivity-experiments.
I'm going to close this issue as part of the migration to the Gutenberg repository. Please, feel free to open a new discussion in the Interactivity API category to discuss this matter further.
from block-interactivity-experiments.
Related Issues (20)
- Decide if we want to expose some parts of the router and/or other configuration in the store HOT 10
- Hydrate islands inside templates HOT 1
- Explore how to integrate the new View Transitions API HOT 2
- Add `data-wp-key` attribute HOT 1
- Fallback to server navigation when fetching on the client navigation fails HOT 2
- Gutenberg repo draft PR - Try: Dynamic text autocompleter PR HOT 3
- Refs are not passed correctly to directive callbacks
- Router: cancel navigation when another starts
- Router: keep favicon when doing client-side navigation
- Helper function for adding data-wp-context in PHP HOT 12
- Router: support hash
- Relative URLs in cached CSS files are not properly resolved HOT 2
- Helper functions for selectors/actions
- Support multisite with subdirectories in `navigate` function HOT 5
- Using useRef/wp-ref to get a reference to the DOM element HOT 4
- Potential JS overhead for URLs or sites that use just 1-2 simple interactivity features HOT 3
- `useSignalEffect` is not working as expected when using `visibility: hidden/visible` in CSS animations HOT 4
- Rename `data-wp-island` to `data-wp-interactive` HOT 2
- Preact fails to reconcile scripts correctly when doing client-side navigation. HOT 4
- The Interactivity API issues/discussions have been moved to Gutenberg
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from block-interactivity-experiments.