- Issue created by @fago
- π¦πΉAustria fago Vienna
Another idea: What about some drush command that generates a vue component for a given content type and view mode?
I already had the idea in mind to create some UI to make it easy for people to copy and paste the starter-component, so a drush command to make the same seems to be a good first step.Still, the drush command does not solve the "copy things to the frontend" part. We could write some bash script and ask people to run this to take care of it, and/or maybe add a drupal recipe action to take care of that part.
Finally, just generating vue components probably ain't enough, to make things nice we probably want to add some styles anyway. That makes me thing that for now the most straight forward option would to provide drupal-cms vue components in a simple nuxt layer which just ships those components. The nuxt layer we could just add to our demo setup, since it's a simple config that people can easily remove when not needed.
- π¦πΉAustria fago Vienna
Discussed this with arthur_lorenz and agreed that atm the most effective, short-term solution is to start with a dedicated layer which we could ship for drupal-cms, thus following solution:
> B) Ship with suiting CE-output config in our recipes + ship suiting frontend components for them. We could ship frontend components by providing a simple nuxt layer that does nothing more than providing those components + add this nuxt-layer in our naked and shadcn demos.
- πΊπΈUnited States glynster
I agree with the layer side of things. ATM I am working on a webform comp and field render. I prefer to keep all the API as json and allow the frontend to render as needed. Perhaps the first step is the Nuxt Layer for admin we were chatting about? Get feedback and testing and that would be one way I can help?
- π¦πΉAustria fago Vienna
> ATM I am working on a webform comp and field render. I prefer to keep all the API as json and allow the frontend to render as needed.
makes sense, but how does that tie into the admin layer? Imo the admin improvements should be its own thing, the webform thing can be as well!> Get feedback and testing and that would be one way I can help?
that would be definitely helpful, yes! - π¦πΉAustria fago Vienna
Given there will be more layers, like https://github.com/StirStudios/stir_nuxt_base/tree/release/nuxt-ui-lupus, I think we should add support for adding nuxt-layers via some optional environment variable to gitpod-links. Then we can easily build links which auto-add the layer as needed.
For example an optional variable FRONTEND_NUXT_LAYER=github:StirStudios/stir_nuxt_base#release/nuxt-ui-lupus could add the respective nuxt-layer to a nuxt-based frontend. I'm adding a sub-task to discuss and clarify details there.
- π¦πΉAustria fago Vienna
ok I added a basic structure which adds a sub-layout for each drupal-cms recipe, so things are organized per recipe. Also this would potentially allow for cherry-picking individual sub-layers of certain recipes if people prefer this vs simply adding all.
Generally, simply adding all layers shouldn't be an issue as long as we only have some components in there, since afaik there are no un-used nuxt components in a code base. They are only added to chunks or lazy-loaded when actually used. Still, when problematic cherry-picking sub-layers can be done.
See: https://github.com/drunomics/nuxt-drupal-cms-layer/blob/1.x/README.md
It also has usage-instructions.What's missing now is improving the github codespaces setup to add this extends-configuration when we want to launch with drupal-cms. For that we have the child-issue π Use nuxt-layers for easy frontend component distribution Active
Once we have established how we ship vue-components here, I think we can mark this done + make individual sub-issues for adding concrete vue components per recipe.
- Status changed to Needs review
19 days ago 1:32pm 7 May 2025