We want to enable people to nicely organize the frontend code. We aid that be providing well-defined naming pattern by default.
Improve defaults in custom-elements 3.x to follow the following pattern:
* For rendering content entities, we do not add a drupal- prefix. We apply the following pattern: `{ENTITY_TYPE}-{BUNDLE}-{VIEW_MODE}` or when the entity does not use bundles `{ENTITY_TYPE}-{VIEW_MODE}`. The view-mode suffix should be optional.
* For rendering any other special element like forms or views, we use a drupal- prefix.
* Additionally, we append form-IDs and view-names to those special blocks, to ease customizing them + improve the nuxt setup to make that easy.
This will result in the following custom-elements / vue components:
drupal-markup
drupal-layout
drupal-form-[...]
drupal-form-user-form
drupal-view-[...]
drupal-view-frontpage
node-[...]
node-article-full
node-article-teaser
node-page-full
node-page-teaser
node-page-search
media-[...]
media-image-thumbnail
paragraph-[...]
paragraph-text
paragraph-image
block-content-markup
block-content-custom
...
The [...] view component lookup logic is something we can work into our renderCustomElements() nuxt function and follows the known pattern of the nuxt page router where [...] acts as a fallback. It should take the full component name, and if no match is found, remove "-[a-z]+" suffixes until one is found. This gives the flexibility to have one component for all view modes or not.
There is some risk of conflict with this naming pattern, e.g. content types "article", "article_teaser" and view modes, "teaser", "teaser_full" - I think this is rather rare, so acceptable and can be worked around by renaming things or using a different pattern in conflicting cases. I don't think it's worth complicating the pattern to 100% avoid conflicts.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
fagoComment #3
fagoComment #4
turtlbbx commentedThis would be a breaking change for existing Nuxt projects. One would have to move components in Nuxt projects in a sub-folder "Drupal" or write additional component config in nuxt config file or have prefixed component names with "Drupal". It adds another layer to think about when developing frontend, I don't like that.
What I'm doing right now in a Nuxt 3 project is, I put all drupal custom-elements in a subfolder "global". That way the components are grouped and are global (Dynamic Components) without the need for additional components config and can be rendered with Vue Render Function API (nuxtjs-drupal-ce renderCustomElements helper uses it). Other components, that are not rendered with Vue Render Function API, don't need to be global.
Comment #5
fagoyes, existing projects would have to follow, but only once the new naming pattern is adopted. with CE-UI configuration projects should be able to use whatever naming patterns are desired. still, we should define good defaults.
Comment #6
fagoAdding some proposal. I think it's not necessary to prefix all content entities with "drupal-" - that makes things to verbose and content-entities names are just a hand-full in Drupal sites, so those would be known and associated with drupal entities easy enough. The drupal- prefix would be there and used for everything which is not an entity, thus more drupally.
Comment #7
fagoAdded related #3463029: Make providing customized CEs easy
Comment #8
fagoThis will be part of CE-3.x - see #3449151: Improve custom-element default names for entiteis
Comment #9
fagoThis is done. So what's missing is changing the remaining custom-element names to follow this pattern:
drupal-markup: DONE
drupal-layout-section -> drupal-layout (it's not a section in drupal speak so let's not invent that here)
drupal-form-FORM_ID
drupal-view-VIEW_NAME
Comment #10
fagoComment #11
fago#3469268: Rename layout-section element to drupal-layout was done in CE version 3.
Comment #15
fagoimplemented and tested changes for both forms and views.
the change is trivial, but for views its a backwards compatibility breaking change for existing frontends. It's easy to account for, but still something people will run into. so let's create a change record. Also it would be nice to be able to configure the custom element name in a view. Added issue.
Comment #19
fagochange record + feature-request created, remaining MRs merged - thus all done!