Motivation

For previewing custom elements from within XB-previews, we need a way to generate that preview.

Proposed resolution

Provide a preview mechanism that supports multiple ways of handling previews. Lupus Decoupled needs one for Nuxt while allowing to add one for Next also. So we need some sort of provider/plugin mechanism.

Usually the same plugin/provider would be used for the whole site, but there might be use-cases to switch it based upon request, e.g. consider domain module / multi-site support.

While it makes sense to ship provides with custom elements module, the module lacks the knowledge/infrastructure to know where the frontend is running. So we could ship with the plugins and let Lupus Decouple expose UI and configuration to select and apply the suiting plugin.

For (the probably uncommon) usage of custom elements without Lupus Decoupled, we could add a dedicated module providing UI / config for that also, or leave it up the site-maintainer to add a glue module doing so.

Issue fork custom_elements-3542938

Command icon Show commands

Start 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:

  • slots Comparecompare
  • 3542938-api Comparechanges, plain diff MR !134
    • 1 hidden branch
  • 3542938-add-api-to Comparecompare
About issue forks

Comments

fago created an issue. See original summary.

fago’s picture

fago
Primary language German
Location Vienna
commented
Issue summary: View changes

fago changed the visibility of the branch 3542938-add-api-to to hidden.

fago opened merge request !134

fago’s picture

fago
Primary language German
Location Vienna
commented

So the preview-provider usually would happen automatically per-request, however there are use-cases where we want to select them:

1) Lupus Decoupled wants to add UI to allow the site-builder to choose from the list of given preview-providers, then apply them to the request.
2) Custom Elements might want to expose a UI during ce-entitity-display configuration that allows multiple preview-providers (e.g. Markup, Nuxt, ..). But that's in the end just two: the markup preview + what is the default for the request.

So it seems, all what is necessary for 2), is the service for preview providers + the way the resolve the right preview provider by request. We just make sure that preview-provider plugins implement PluginInspectionInterface - such that custom elements has the metadata about the resolved provider.

for 1), Lupus Decoupled wants to configure its own preview-provider-service based upon the configured plugin, so it can be resolved.

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Active » Needs review

ok, finally I've got something which I think is ready to go. It lays the ground-work, such that we can add individual preview-providers in separate issues now. For now, this will be #3548197: Add a Nuxt preview-provider using the nuxt-component-preview module with hopefully some next.js preview-provider following soon.

The architecture with both tagged-services and plugins might seems a bit overwhelming, but in the end we need both. I tried documenting it nice in code/interface to clarify what is the purpose of each.

useernamee’s picture

useernamee commented

The architecture with both tagged-services and plugins might seems a bit overwhelming, but in the end we need both. I tried documenting it nice in code/interface to clarify what is the purpose of each.

That was my thought as well. I did not find a place where the need for both is explained.

fago’s picture

fago
Primary language German
Location Vienna
commented

I commented at the MR. The docs are at https://git.drupalcode.org/project/custom_elements/-/blob/6dd32efafbc7ad... - does that explain it to you?

Additional background can be found at comment #5. I wrapped my head around it, but could not find a simpler way to achieve it. It might be more logical if lupus-decoupled would provide the plugin-manager, but then I think it's useful to have them in custom_elements module, so it could be used easily by any kind of decoupled-setup with having to use lupus-decoupled. One would have to provide necessary glue to provide the base-url, but that could even be done in a custom services.yml in a project.

useernamee’s picture

useernamee commented
Status: Needs review » Reviewed & tested by the community

Passed technical review, but there are still phpcs and phpstan failures.

Internal discussion:

The comment in the CEPreviewInterface describes the situation but doesn't explain what are the limitations of plugins and the need to implement them as tagged services as well.
I wonder why resolver does not get injected the plugin manager and get preview plugins already collected by the manager? The only difference I see is that tagged services have the weight/priority and the plugins don't - but we could add them as a plugin config option and have them ordered that way.
I see that plugins are the way to have config option selectable in the UI and are thus needed. But why can't the plugin manager just implement getProvider method and use it instead of resolver?

well, not a limitation really, a different purpose. the plugins are available plugins to be applied to requests, but need config (base-url) first. they really are for provding configuration options in the UI. the services are for selecting the (configured) provider to actually work. (-> think domain module, select the right provider for each domain by request)
interesting idea with getProvider on the manager.
the plugins are not usuable yet, they lack the base-url when returned from the manager. there is no layer really where to add the base-url that would fit there I think.
it does not really fit for the domain module use-case also, e.g. when there are multiple frontends, with one backend, you migiht have multiple instances of the same plugin, with different base-urls. you can do this now by adding respective services on top of the plugins. but you cannot have multiple instance of e.g. "nuxt" with multiple base-urls in the manager?

  • fago committed 4d83584a on 3.x 
    [#3542938] feat: Add API to preview custom elements in Drupal

By: fago...
fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Reviewed & tested by the community » Fixed

Thanks, moving on then!

The phpstan issues are already resolved in the next issue, so let'S get it addressed as part of it then.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.