Comments (5)
Hey MatΓas, thanks for chiming in because, as far as I know, most of the contributors collaborating here are not familiar with Gutenberg nomenclature yet (me the first!), so the sooner we learn about it, the better π
Can we consider whether
View
is a better nomenclature to use thanFrontend
Sure. I used the frontend
name because there is a possibility that we want to differentiate between the current view
script enqueuing behavior, which is always enqueued, and an enqueuing that is deferred in time based on the different hydration technique, which may need a different name. But it's not even clear if we won't be able to do so with backward compatibility with view
, so I agree to keep the view
name for now. We'll make a PR to change it π
wp-block
vsblock-
instead ofgutenberg-
This has been more of a surprise to me.
So it looks like Gutenberg is only the project name, but none of the APIs should have the Gutenberg name. Is that correct?
On the other hand, now that Gutenberg is being adopted outside of WordPress (Drupal, Tumblr, Laravel...), using wp-
feels a bit weird to me.
Should we try to use a generic block-
name then? It looks nice and clean, but it feels a bit riskier because both the event and the custom element namespaces are public.
<interactive-block>
<inner-blocks>
new CustomEvent( 'block-context', {} )
And what do you think about wp-
? Is it ok to use, even if Gutenberg is used outside of WordPress?
(Maybe as a reminder that Gutenberg is still a WordPress initiative π)
For what is worth, if I had to vote right now, I think I'd go with the generic names.
from block-interactivity-experiments.
I recall the wp-
prefix was configurable at some point, at least for block parsing + serialization, but it's also hardcoded in many classes, docs, etc. I'm fine trying the generic block name first, though I don't like interactive-block
:)
from block-interactivity-experiments.
I recall the
wp-
prefix was configurable at some point
Oh, that's a good idea if a prefix is unavoidable. However, I'd use it with care because it could cause extensibility problems (generic code that needs to target wp-block
, drupal-block
, xxx-block
β¦).
though I don't like interactive-block :)
It's true that we could end up using it for non-interactive blocks (maybe to store things like static Block Context) and it's not part of the block itself, so what about block-root
?
<block-root>
<div>my block...</div>
</block-root>
from block-interactivity-experiments.
wp-block
seems better than block-root
:)
from block-interactivity-experiments.
I've opened a PR to make these changes.
I'm still not convinced with the wp-
prefix coupling, though π
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.