Decoupled component builder

[rlnorthcutt]

https://git.drupalcode.org/sandbox/samuel.mortenson-3070857

We need to look at creating a revisionable entity and this code to create a decoupled component builder. User story:

1. Add "new component"
2. Fill out form - js, css, template
3. Save component
4. View is a rendered example
5. When component is published, it shows up in the block listing

We should also look at adding React/Redux support for this... common Redux store, common React libraries that are used, etc. Maybe we need a mashup with PDB as a dependency

[saltednut]

Adding a UI to this definitely seems like the most low hanging fruit we could go after.

We'd need to create a SingleFileComponent plugin instance (DynamicSingleFileComponent) that receives the constant info from some type of "bridge" entity that gets loaded when its dynamic instances are registered. Given the requirements around putting it on the page, a block plugin does make sense so we can start there.

It sounds like you have some specific followup ideas re reduct/react too, which is awesome.

We should also look at adding React/Redux support for this... common Redux store, common React libraries that are used, etc. Maybe we need a mashup with PDB as a dependency

Might work better as a followup or related issue?

[rlnorthcutt]

What if we just extended the "react_block" module? We get the react/redux for free, its already in contrib, and it is already used for ACF. If we extend that, then we immediately get this functionality in ACF and demo.

[saltednut]

Yeah that's an idea. I was just trying to extract some focus out of this particular issue and perhaps spark up a few new issues to stay organized.

[saltednut]

Adding a UI to this definitely seems like the most low hanging fruit we could go after.

Its looking more like we'll need to design our own block plugin that uses this paradigm, but instead lets people do this via a simpler method. Really good reference architecture though. I still think we can build a bunch of plugins with PHP constants, but the code is really locked in with using them. If you wanted to build a super-locked down library of components that users could use, this would still be the way to do it. So I suggest we pivot here and do two things.

1. Use constants for the sake of preventing anyone without codebase access to be able to mess with a component. Build a block plugin that loads the list of SingleFileComponents and render them wherever the user wants instances.

2. Build a block plugin that mimics this component based design paradigm in Drupal with 3 fields (see "fill out form" in the OP). These blocks would then bring with them those three things, css, js and template.

[rlnorthcutt]

I like it.

For option 1, that sounds like an approach we might could use for Lift/Mautic demo stuff. Invisible pixel that tracks views, or passes user behavior to Lift via JS (like starting to fill out a form, or abandoned cart). I got the idea from this.

For option 2, that definitely sounds like an extension of react_block. We just create a submodule that provides a UI and a revisionable entity to store the data (css, js, template). Thats part of a broader refactoring that needs to be done over in the module. I'll open an issue there.

Maybe we should reach out to Sam? Get his input? He is working on it right now as I type this 😆

[saltednut]

definitely sounds like an extension of react_block

Yeah, I was thinking something similar. A patch to the react_block with a submodule might have a good chance of getting committed. I don't mind asking @mortenson what he thinks of these ideas. The worst that could happen is no reply and we'll move forward?

My misgiving here is wanting to avoid misusing any api, or forking this into a monster asset injector that we're stuck maintaining on an island in DF. SO I totally agree we should look at the contrib that's already doing stuff like this and try to add to it.

[mortenson]

1. Don't base any code on the sandbox - it's a sandbox and can change at any time.
2. The single file component base is already kind of beastly, but you don't need to use it to write single file components. The interface and plugin annotation is quite small if you want to define CSS/JS/templates without constants. Since it uses the plugin API you could derive plugins from anything including content entities.
3. If you let users enter Twig templates in the user interface it'll allow remote code execution (https://www.drupal.org/project/drupal/issues/2860607).
4. If you let users enter CSS/JS in the user interface it'll allow for cross site scripting.

[saltednut]

Indeed, the sandbox can change. We're not naive to that! There was some talk on twitter about considering an official project so we had a branch cut just so I could build something. (One can always fork but thats not really the point. I get what you are saying.)
Especially appreciate the security warning! It's something on my mind here too. Very kind of you to point these things out as they are both glaringly obvious yet overlooked elephants in the room.

Ron, I'll leave it up to you to explore the UI based approach further. I'm still in the mind that we should build some components first and allow for a block to be a component selector. There's a lot of very cool "widget" types experiences that could be built with forms that don't require exposing raw twig templating or CSS/JS too.

[mortenson]

@brantwynn Following up on this - have you used the Snippet Manager module? (https://www.drupal.org/project/snippet_manager). It seems like what y'all are looking for, it lets you write Twig/CSS/JS in the UI and use those snippets on the site.

I also released alpha1 of sfc if you want to try it out https://www.drupal.org/project/sfc

[rlnorthcutt]

Wow - the snippet manager is pretty slick looking! I still think we can use this as inspiration (and to steal code from) for sure. One of the immediate things I see is that this uses config entities for the snippet stuff.

I think we would want a content entity so that we can revision it. Thats one of the problems I have with asset_injector (no revision). I also think we would want to extend the PDB or react_block modules so we can create different types of components (React, Vue, Ember, Angular, etc.)

That being said, I appreciate the tribal knowledge share. I had no idea this was even a thing!