This is a transcript. For the full video, see Tag1 TeamTalk #019 Enabling Declarative Components Everywhere: Drupal + Web Components Out of the Box - Tag1 TeamTalk #019.

Preston So : [00:00:00] Hello and welcome to another episode of Tag1 Team Talks, the webinar series about emerging web technologies. My name is Preston So, I'm your host and editor in chief at Tag1 Consulting, moderator of the Tag1 Team Talks and also senior director of product strategy at Oracle and author of Decoupled Drupal in Practice. We've got a really exciting show for you today. We're gonna be talking about the idea of how we can introduce more frontend components, and the idea of components into the Drupal front end. I'm joined today by two of my great friends. Fabian Franz, who's based in Switzerland, senior technical architect and performance lead at Tag1 as well as Michael Meyers, managing director of Tag1.

Without further ado, let's go ahead and jump right in. So, Fabian, I know that, last year you gave a really exciting DrupalCon talk about this idea that you've had for a long time that has been percolating throughout the community for awhile as well, about this idea of Components Everywhere. And there's a lot of people who have different visions, but can you tell us a little bit about what was the main thrust of your idea behind Components Everywhere.

Fabian Franz : [00:01:07] The main idea for me, like the ultimate vision, is that you build an app, backend application in the exact same way as a front end application, purely data driven. That without having to, know anything about APIs or decoupled or anything like that. So the, the main gist and the idea was to decouple Drupal within itself. The data within itself, so that was kind of the, the main thing. And then. Put lots of technology around.

Preston So : [00:01:40] So let's talk a little bit about some of the key concepts that you'd spoke about because this has been a very exciting topic. I think a lot of us in the decoupled Drupal kind of, either have talked about this idea of how do we decouple Drupal within itself?

You know, we had a talk, I gave a, hosted a little panel a few years ago about decoupling Drupal from the inside out. That was about some of these ideas. And I think that you've identified a really interesting axis to, go down in terms of really looking at how can we actually do this decoupling from the inside of Drupal, but at the components level and driving this kind of ability to, still have that relationship between server and client really clearly established, but have these shared components. So what are some of the key concepts that you identified during your session? I mean, I know that you talked about, you know, what components, but let's, let's, let's talk a little bit about, some of the ideas behind, your dream and vision.

What are some of the pieces in Drupal that you're talking about? and what are some of the ideas? Are there custom elements involved? What sorts of things are you talking about when you say, purely data driven components?

Fabian Franz : [00:02:46] So, the main idea is basically you have achieved success when you are able to use the same component front end and back end wise.

And, it's only the data that is provided to the front end and everything continues to work the same on the back end or on the front end. You don't have to do anything. That's basically, again, the very abstract idea. Now in more concrete terms, one of the key concepts, what you need is obviously components and I've talked a lot about that theme functions that are similar to components, but then now I've, I've identified the gap. The thing that's kinda distinguishing theme functions from other things, and that is the missing slots. Slots, the ability to basically have a component. If you have something in there, which is then, at some point, I ran that as part of this component.

Basically this whole concept of children that we have in the render tree. But we, we, never explicitly made about that. This is basically like a slot for a component that we are rendering those children or those attributes or those things.

Basically, we have all the concepts for a component based system within Drupal, which is one of the, in my opinion by now, one of the reasons it was so hard to implement. One, because whenever you start implementing it, you get the feeling of “Oh! We already have that!”. We have this, we have that, we have that we have it all already, why should we reinvent the wheel?

And, people have Laravel, for example, they just have templates and they still introduced a component tag. To their BladeX templating system. And I found that interesting because it makes the distinction much more clearer of what needs to happen here. Yeah, so components are definitely a key part, and the Theme function is so similar to a component. Or a Twig template is so similar to a component , but it's still not the same. And I think it's very important to try and understand this thing. Yes, you can implement, for example, slots with Twig automatically basically in that saying, because everything you have in the templates to do that, but it's still not the same, mindset wise, of writing them.

And another huge part is Turn tags. And again, I didn't know that Blade X existed at the time of my talk, Laravel just introduced it in Laravel 7 and made it a very clever trick in being able to identify all components. They just all prefix them with an X. So, for example, if you have a large component, you then have to have this huge racket of all possible component names in your system.

You just search for an X dash whatever, and you find all the components and that way. That's another part that I talked about in my talk. As a developer, you want to be able to write HTML. That means you want to write. X alert. Set some properties and that's your allowed component.

You don't wanna use a Twig syntax. You don't want to use a component and Laravel's got that.

We talked about that before, in our previous Laravel talk that they are very pragmatic. They're very developer -and concentrated, while we in the Drupal world be often very much like trying to aim for perfect first, and they're going for pragmatic first.

And, Blade X in that respect is very interesting in that it also kind of like, started out within the contrib world of Laravel, like as a contributed library. And then it got into, into the core of Laravel as it was so useful and fun. But while getting into core, they kind of like have this great idea of being able to efficiently pass all those components.

So that's the second part. First is components, second is nice syntax to, to work with that. And, the third thing then is it's kind of like the interactivity again. We have something like that already is Drupal Ajax. It's perfect. It's great. but. It's tied to Form API. It's very hard to use. And again, Laravel introduced recently something called Livewire, where you have principle again, the concept that Drupal Ajax has since ages, but again, implemented in a way better form or idea, that makes it possible.

Basically, we have the ability to update DOMs server side. But what we don't have is basically the idea of, and maybe you can talk a little bit more detail later, is of, of having the data in and out. because that's what means the other key concept that I've talked about in my talk was a store.

Basically, you want to have a store provider, something that provides through the data, where you can get it out and can update the store. And then it is, and again, Livewire is implementing parts of that again, by, for example, that you have like a server side message adds to the counter, increment counter and then you just call that.

And Livewire automatically knows that it now needs to change the server side store and then return the new state to the client.

So, I learned a lot about kind of like what the, what the ecosystem now provides here. so that's really, really fantastic. but yeah, we still need to bring it all together.

Preston So : [00:08:27] Yeah. And I think you've identified a couple of really interesting points here. The first is that, you know, components and this idea of supporting components and data components is not something that's really new. To a lot of these ecosystems we've seen, as you mentioned Laravel, really emerge with this amazing, Blade project, right?

This, this component based kind of tool Blade X, that really integrates nicely with Livewire. You've identified also Drupal AJAX, which I think we can both agree is a bit of a more, let's see, outdated or anachronistic way to do kind of component driven, kind of work. There's a couple of other projects though that I think it really just needs to look at, especially as we start to look at web components.

First of all, there's the web component server side shim, right? Can you talk a little bit about how that fits in, in terms of this general landscape of, of components, in the front end.

Fabian Franz : [00:09:20] Yeah. So, there has been this, this, initiative that I think ultimately did go into this next stage where they tried to introduce web components into Drupal and, they basically, tried to, And I do think we are not yet there. So, web component is not components. That's something many people don't understand yet. Because we defined a component as HTML. Oh, we have encapsulated JavaScript, and we have encapsulated CSS basically and web components go one step further because they have Shadow DOM.

And that means they have a complete encapsulation automatically, basically.

And then you have other things that are either living in the Shadow DOM or in the Live DOM. It are then further trickling down these components. So, um, Shadow DOM, basically in this case is it's like a little bit of like a game changer, in all of that because it allows you to have CSS, which is not affected at all by anything that came before.

As I've said before, another way to do it is basically to use, class-based. CSS. utility based CSS. Like Tailwind. Yeah. Funnily enough, if you have all styles directly on the elements itself, you also never have to deal with cascading problems, or at least not in the in the effect of the original CSS case game.

So, both Shadow DOM, breaking the cascades, Tailwind not using the cascade at all. like giving into this direction of, maybe this CSS cascade was a little bit of, like. Bad design in that, as like UI systems. like if you look a little bit about the mobile application and how they have those, native applications, how they are styled, there's also two new ways to for example, use React like the React Native and, just other competition, not from Google.

Preston So : [00:11:30] Yeah. Flutter.

Fabian Franz : [00:11:31] Oh, yeah. they basically, show you can build a, like, like nice layouts, completely without cascading. Also all React based components where you add, CSS, was, for example, CSS and JavaScript, CSS and JS. All of those don't make use of the cascade at all. So basically everyone is going away from this idea of that the styles are just cascading down and, more defining this is my element and it's syntax. And, now naturally everything that comes below it would be centered as well, but not due to the cascade, but just because the parent is centered and I think that's a shift in thinking about those things, that basically, we also have to distinguish between layered components and style components a little bit more. And, they have many ways to roam, but the way of the web components is basically to use the Shadow DOM and break this. And, one is the thing that however, is missing for web components is. They are JavaScript only.

So they are non-declarative right now. So you always need to launch your component first , for example, from HTML module. Then you have to read just that and just then the browser can actually display it correctly. So the platform is not there yet. I would say as a, as the same. because the web components in that, what you really want, if you want to use Shadow DOM, is not just the normal Shadow DOM being attached, et cetera, but you want to have like a declarative rate of Shadow DOM, where wherever you want you can break the CSS barrier and you can say, from here, I've put a new route, which is like an, I-frame without the problems of the I-frame, like from here, there's a new route and, from here my styles are broken up and new styles, are only taking effect in that. And, I've heard from browser vendors, those, not directly, but on Twitter, that this is freakingly difficult to implement. The Shadow DOM itself was very, very difficult to implement already. but, declarative Shadow DOM seems to be on a completely another level again to implement this. And there's, for example, Shims. Where you can, for example, has like an ex Shadow route element, and then you log some little JavaScript and it automatically creates your Shadow DOM .

So there's lots of ideas in the web component scene as well, here to solve that. But this makes the server side, rendering so challenging. And this was one of the ideas that Sam Mortenson, who contacted me after the talk and said he found it interesting. And this is where he had gotten to before, was going with the server side web components Shim, basically, that he also implemented all of the Shadow DOM and tried to simulate that, either via classes or, might be wrong here. but he tried to assimilate basically this shadow dome approach using some different techniques. and so then be able to complete you when does this trick component on the, on the server. And, I think that's an interesting idea over all this, and that's kind of what it said.

We need to Shim for web components. In all my research. and I think web components are still the future, but I think there's still some things missing until it's ready for, like declarative Shadow DOM might be really the game changer of, of being to use it. but it's also, in many things if you first handed them need or don't want, Shadow DOM because you're using Tailwind.

When you are very happy with this - your styles already, and your components interacting this each other, then maybe you don't even need those, those type of components. And the other parts of what web components, is giving you basically the custom elements. And that's more a question of who ran nasio sayings.

Is it the browser or is it whatever technology and you want to do. And again, they ask new, interesting points of that. there's two new libraries of, but maybe you can get to that a little bit later, of a JavaScript template. That's was amazing in what they allowed to do with a little HTML, doing more things.

So that's, but really, if I were to implement this. Like, this whole saying, I would not bet on web components right now, but more on components as a level and then have, have it be, is it a web component? Is it a group component, react component, twig components, whatever. as an implementation detail and not as the overall important thing, the important abstraction layer as a component.

is less relevant and it's the data that flows into that component. It's less relevant of who in the end is, is displaying it or doing it.

Preston So : [00:16:45] Wonderful. And I think that's given a very good summary of some of the issues behind web components and some of the problems that we know we have in terms of really allowing for this kind of idea of universal, that components, right? Both server and client having access to these same components.

There's one technology that I know that you have spoken about in the past as well called Inertia.js and, and this is a little bit less to do with kind of a component base rendering, but more to do with. Routing .

What's the story behind Inertia.js And, you know, I know that it's one of those technologies that you looked at after the talk.

Are there any conclusions that you would've changed based on, learning about inertia and learning about Inertia?

Fabian Franz : [00:17:25] So, those, Livewire, Laravel Livewire , which was just released and Inertia.js. I didn't know what they were at the time of the talk. Inertia.js basically, it's more to, it's, it is for, the idea is very similar to, What I've outlined as the ultimate goal to write a single page application without writing a single line of JavaScript, and it's great that they're implementing that. They have bindings. Right now for Laravel, and for files, as l remember. And, but the, the important thing about Inertia is basically, that you can write normal controllers and you set them up in a special way and then you are giving back data.

So that's a little bit to my data driven approach of that. however, and then basically whenever I do have something where only the data changes. Then it just changes, the templates on the client directly, and then you can feed Vue.js With it and, and, and as other things, also, if you want to, sort of allow us to do that and whenever it kind of changes completely the context, then it does a full server side request.

So basically whenever you click on a link, it decides. Can I do an Ajax request? And if it can do an Ajax request, then it gets back just the data, updates the data and gets back to a result immediately. But if it turns out when you get back the data that for some of the hash has changed because, some page layout or whatever has changed or the data is no longer compatible this what's on the page right now and you really needs to navigate to a new page.

Then it does another full page request. And loads basically a new state of that. So it's, it's giving you basically, it's an interesting way to implement something which allows you to get more, to a single page application level without having to really write Java script or change spec and et cetera.

For me. and, for me, it doesn't go far enough because in Drupal, we don't just have like pages, like an event or something that, but you also have lots of other objects on the same page. We have blogs. We have a complex API. We have a form. We have, we have so many elements like that, that this doesn't really work.

I mean, it's bothersome, I'm not to be me as experiment. This like implementing Turbolinks for Drupal . Which works well overall, it because, with dynamic page cache. We exactly know like, is this page similar to this layout, etc. and, we can do that and then we can just update kind of like those sections that actually have changed.

But again, this is not, it's a nice approach. And definitely workable. And if you want to do that, check it out. and find some of the people at base camp, they're saying the mobile apps, it's. Pure Rails plus Turbolinks. And it's fast enough and good enough in that. So it's definitely possible to, to build an app like approach just with the idea of Turbolinks or just this plus the idea InertiaJS, etcetera.

but really this is more replacing the need for React router, as the Vue router as those things. And. In my vision approach proposal, I pose this whole thing. This is not even necessary because, you know, Inertia would be happening automatically, basically. You would never be, be tending just to Patriot class two would also be signing always the data.

There's some drawbacks to that as well, obviously, because I'm, yup. Payload gets, gets larger in that. but, yeah, that's, that's, that's a problem in general. I followed some Twitter discussions again, of React folks in this case and basically this server side rendering, it's always a problem of the server side runs something and then you have to push also the whole data tree basically to initial state.

To rehydrate the application. Rehydration takes a long time. So it's a really unsolved problem. So nothing too. I mean, if they, if they really huge team of React and innovative, again, again. Have not solved it yet. It's definitely still something that's challenging to solve in that. And, yeah, another thing that I basically learned since then is it's a little bit, that, perfect is the enemy of good enough.

So, I am probably tried to do a little bit too much at first just looking at solutions like Inertia.js or Livewire. They just focused on one part of the problem and solved it really well and provide a lot of value and I think that's good. Good approach to go. Basically to just start somewhere for time would be, could, could just take Laravel X Blade renderer, rec X.

That they've already built, thankfully, and virtual robust and work, good enough for them. Take them as, as a library in. And then, use it just in Drupal, and we can have a nice syntax already. But for example for the components module. So that's one of the things.

Preston So : [00:22:43] And I know that, you know, you've, you've, you've learned a lot of lessons from, this research that you've done and looking at a Inertia, looking at a lot of the ecosystem that's available in Laravel.

What was the interest level like in the Drupal community? I mean, I know that you started a channel in Drupal Slack, obviously, I would've very much looked forward to. talking with you about this in person, in Minsk, in Frontend United. but, obviously, that's, that's, that's not gonna happen.

I'm curious, what's the level of interest like from the Drupal community and what have you been able to accomplish, in terms of spreading the gospel, not just, you know, the, the kind of technical underpinnings, but also convincing others of this approach.

Fabian Franz : [00:23:22] Generally, there was a huge interest after DrupalCon, interestingly the community impact was much higher than interest for core maintainers. So that was the most skepticism, both basically on the, on the core side, but also in just prototyping an urgency, but what I can do, I get pretty busy, I must say. So that, really, my next step was Frontend United Minsk to get to an actionable plan, work directly with the Frontend community and the next step.

I've already gathered some folks who are interested and eager to do something. And again, my. I was not yet able to kind of formulate an action plan of what to do, where to start, how to go. And, so that's still the next step. And basically that was what my presentation in Minsk was about, compounds everywhere, the next steps basically. Where do we go from here and, and, and how do we do that? I still believe that overall on my, my whole, my whole approach of, of completely decoupling the data is in the end. Harder, but still superior to something like Livewire where you have a mix of defining data on a component.

Like you put this in --- or whatever, and then you are uptaking this data and then you do that. And, I do also think that Drupal has this huge opportunity to, for example, say, these components have dynamic data. This is data that the never changes. Like. Unless we do a full page request or whatever, and we would have the ability to say like, this doesn't ever need to be rehydrated anyway.

We can have just aesthetic page scale upon basically very similar to how dynamic page cache has the skeleton. And then you have some Facebook filling in the blanks in that whole thing. And, I do still think there's a huge opportunity that efforts at the front end community really hasn't solved yet.

In that we do exactly now what needs to be interactive, what doesn't need to be, or we could have, we could create a language, but basically, you were able to, to do that. And, you could determine this block really should be interactive because whenever someone takes a flag, I want that to automatically update.

But this block doesn't need to be, etcetera. And that way, again, are giving the developer the ability to specify what's interactive and what's not. could make it easy to for example, but not having to push the whole tree, but really only what can change on the page. And, yeah, I still think I'm over. The trend goes back from purely front end things to more like Laravel, Symfony, Rails a traditional page controllers, things it's supposed to ultimately.

Interesting. There was a talk, about, 2020, from, they basically a React request, tries to, simulate a traditional page request. So it was interesting because they wanted this hooks and everything. They've wanted to get back to the simplicity of PHP, just not this, all the problems, but basically where the idea of hooks and all of that was basically that you write code, like it's 1999, again, like, like a traditional PHP app. And, we have the PHP still and I just think, we have huge opportunities to, to get back into the market and, make it easier and Laravel I must say it's a huge, Front runner here in, in showing us how it can get done in terms of innovation and other things.

I must say that just, it's just really, really amazing. And yeah, so that's the point. So if example, in Livewire it works like, you, return, the, you return the markup like we doing, Drupal Ajax and the data and then your updates, both to data store on the local side and the and the markdown.

And then they use the DOM Dev Library to seamlessly update that something. For example, we should be, should just implement in Drupal Ajax, just use that same DOM Dev Library. And whenever we replace something with Ajax, we are not updating the DOM, like with spits all the even handouts, et cetera, having to run again, but really only what has changed and if something hasn't changed, we don't need to reattach behaviors, et cetera.

Preston So : [00:28:08] It sounds like a lot of these ideas have been, you know, kind of cycling around for quite some time. you know, a lot of what you've just mentioned is very critical, I think, to the, fundamental foundation that underlies, virtual DOM for example, right? Instead of re-rendering the entire DOM tree, you're only rendering the portions of it that have changed for the portions of it that are computationally more complex, right?

As we've seen with cache-ability made it that way in Drupal and the ways in which you can, you know, indicate to dynamic page cache that, Hey, this, this is much more dynamic than this part.

so

I'm kinda curious what exactly, Do you think will need to happen from the syntax perspective? You know, I know that one of the things that you've talked about is the fact that a regular expression, you no longer have to go through and look at every single possible custom element that can have any kind of nomenclature, but you'd only have to look at things that are prefixed with X.

Like x alert. Right? I know that one of the things you'd examined is that a twig preprocessor could just could just do this and it would be just nicer to work with. could you talk a little bit about what's the relationship like and, and what does the juggle look like between things that we've introduced from the Twig ecosystem and new things that we'll have to introduce from, let's say, outside the Twig ecosystem or things that we'll have to invent?

like w you know, the kind of thing you just mentioned around. Having that rerender of just portions of the page in the Drupal Ajax framework, for example, do you see other things that will need to be outside of Twig or replaced with altogether, potentially, or, or, you know, how does Twig kind of play out and your vision for, let's say Drupal 10?

Fabian Franz : [00:29:43] So, In terms of being able to be a client site language as well. Twig is the worst you could have.

And Laravel has the same problem with Blade because Blade, Twig, et cetera. They are all declarative languages that in the end compile to a string. That's also why Livewire choose basically not to send a template for the time, but directly send, say the markup and say, Oh, all those libraries have virtual dom basically, and have a data tree.

Our data tree is the HTML itself, kind of like, like, like explaining it like this. And, if you're, if you're taking this, this approach. That's basically what we do with Drupal Ajax as well, really he, just that they made some very, very nice developer experience around it, et cetera. So, but, your question was kind of like, how does Twig need to change?

So, Laravel did not, like I over think it and, said like, Hey, you may need to render a template first. I mean, you need to, to check this. Basically they say, Hey, we parse your HTML component, and if you use X, whatever, and you do it wrong and you try to piece it together out of several strings, then you will get a pass error.

That's it. So again, a very pragmatic approach. That's basically, you don't have to think about all those educators, all those things that code wrote wrong, and instead to you were just saying, man, Hey, if it doesn't pass, you'll get a Pass error. And I think that the pretty pragmatic approach also, if you want to bind a variable.

And then use the special syntax that you're used to from Vue, from Angular, from whatever like that. Just introduce the same concept, use it, and, and do that and combine that basically with the component that they already had since five or six or whatever, a version and do that. So again, in Drupal once we have a, like a component Twig tag, with the slots syntax, with everything we need and, do that, then we can have the nice sugar on it and it even an include already can, can have a nice syntax.

So basically the idea was, and John Alban again was very active here. Yes. But in a components module. And, Components module probably stole our best that in trying all of those things out. And then he wanted to introduce a nicer way for core to, to create the same template and just to add some nice syntax numbers, like, hey, why not just, well that directly, like, instead of having like this include whatever, but I've components sanction and HTML speak, or what am I like that.

Why not really? Just, just write a log directly. And I still think that's the nicest way to, to write a web application that, assume that, you could, could just, whenever you were in some render tree or whatever, you would just write x-alert. As a, as a trick template, basically an inline trick template somewhere.

Or in some other trick template. You write this x-alert and, and it just works and, there's your alert component and you don't have to know that you need to call theme or you need to construct this render array or whatever. And the nice thing about this is the syntax is it frees us. From all of the old things.

It didn't remove all the other things that render tree is nice, but we have pre-render pre-process access. We have so many things mixed in the render tree. That you originally needed from Form API, and then we blow it all up. So using components, the syntax, the simple component that just purely data driven and, can then be attached, for example, to life cycle methods, which is basically the main thing that Livewire, brought two to two things, which you need for, for the frontend.

And then you can have like class-based components, which perhaps those, more lifecycle things. Then you have some ability to kind of start over, find it, and leave all the baggage behind. It's, it's still not, it's not a new system. It's still interfacing with the other things but where we need to go with in Drupal is in Drupal 10, in my opinion, the most.

Is to remove layers because all we did from Drupal 4 to Drupal 9 is add layer after layer, after layer, after layer, after layer, after layer. And that works to a certain extent, and it's a nice way of, of doing things. but it's not scalable. Ultimately . And one of the reasons we needed this very nice performance system for Drupal 8, was because, just adding Symfony and putting all the Drupal we had before on top of it. It was just a nightmare for performance in that, that, this caching, we could mitigate that. And it's gotten faster in many, many cases because we are catching so well now. but in the end, in many applications, like a Laravel Symfony world, they are like, why would we need to cache cache?

Those same things, we are fast enough out of the box in that, and Drupal could go there again as well, I think, but the only way to do that is to, to cut fat basically. And, and. Start over with modern things. And, this component thing is, it's one huge chance of having a component not to go through the whole theme system, not go to the whole thing, but really just go directly to the components, et cetera.

And then obviously, yes, for sure. One needs to saying, what about themes itself, base themes, et cetera. So maybe you can cut all fat, but for example, just cutting from the render tree. A lot of things. I think that would already be like a huge advantage in being able to do so.

Preston So : [00:36:08] That's amazing. I think you've outlined a really incredible roadmap for the ways in which will enable Drupal to really engage in a much more modern friendly development experience.

I think this has been a big complaint, but it's also been a very intractable problem for a long time, and it's really amazing to see that you've identified not only all of the pieces that we'll need in the front end, but also in the back end with all of these, abstractions and it's really amazing to see, I want to talk a little bit about the data, right?

So we talked a lot about the syntax. We've talked a lot about kind of the, the, shared component architecture between server and client, but we haven't talked so much about the data and the data store. Right? And one of the things that, you know, I've spoken about in the past is the ability to, for example, if you've got translations, leverage Drupal settings on any front end application.

What sort of things do you see in terms of opportunities for a potential more overloading of the Drupal settings object? You mentioned earlier, React provider. I'm kind of curious, you know, now that we've talked a lot about sort of the syntax and how the components will look. What exactly does the data look like?

How does it get stored?

Fabian Franz : [00:37:14] So, many, many more complex applications has this concept of a store. And the store space is the one thing that is responsible for mutating state.

All state is a model by a immutable, immutable, by default. And, whenever you create. Whenever you modify state, you create a new state.

Basically. That's a whole idea of immutableJS. In Facebook written a whole app it's one as part of it called draft JS, that's based on some long immutable JS. And the idea of immutable state is that you can also go back to an older state because basically a state is just a snapshot of data. And so at certain point of time.

And then you do, do an operational as a statement, then it moves from one state to another, and some of the stages persisted as a state is not persistent. And that's basically the, the high level overview of that. And for example, the initial state of a page, you could, could by default , just put it into Drupal settings, like, like that.

but now you still. When to inject the States and you need to get the state to the right components that are then in the end ultimately are responsible for for doing that. And the way you are doing that, is you put it into the data store and that was a data store needs to go to the components itself.

And for example, in Vue you have a director so you just inject a store in all components. That's the way they do it. But in React , for example, you provide a provider. So you have a consumer, you can have a provider, you have a provider for the store, and then the storage, it gets, provided, by the provider, and then the consumer can basically inject it into those components that need it.

And that's again, one way to get it, get it down to, to that. and, this again allows you to make your components pure.

So for example, if you think about the traditional JQuery component, they got their Drupal settings injected basically as part of their constructor. And, the other components really don't have that, but they have this concept of the store. So this is how we can get those configuration as well as data to add those components.

Preston So : [00:39:42] Wonderful. Well, we are running a little bit short on time, so I wanted to ask a bit more of a community question. You know, I think there's a lot of folks who are very, very interested in this.

You mentioned some folks who are friends of ours who are already working very hard on these problems and thinking about these problems, what are the next steps in your view? Is there a particular call to action you'd like to share? Are there ways that people can help you with this idea? obviously, especially now that most of us are not able to meet at events and physical contribution spaces.

What are the best ways to get involved?

Fabian Franz : [00:40:15] In general the best way is, to go look on a Drupal Slack channel. But, really, I think, the next step is for me to formulate an action plan for this, an official initiative and, yeah. And maybe even if Frontend United is canceled, give a quick presentation of what the next steps are, all that we talked about, just in a more, more thing.

Then maybe do a webinar, whatever, add two to get, get the ideas out there. Like, like, like this talk and, yeah. And, the next step is people could experiment this components module. They could experiment with creating a components trick tag, which is challenging. It's not easy. Because you have to implement all of the slots, et cetera.

Could look at how Blade does things, a Blade X testing and no Blade. could look at how some of that could just right now work on using this extract X and just try to, to see what happens if the, if you've for example, render a Drupal page like normal, but whenever we render something like, like a theme function, we would definitely, we would just output X-entity, for example.

How would a page look like? Just it, it wouldn't be styled or whatever, but just how would the HTML look like of a traditional Drupal page. This would be one experiment someone could do. and I would like to. Now we'll do the spec ex, check all those things. And then allow just, just allow take a simple alert component and see how it can be implemented nicer.

That whenever I want to write in a lot on my page, or if I want to write whatever on my page, I'm like, listen, some documentations section and just, How can I use, not include but directly write x alerts, like what does it entail? How does it work? And yeah, basically I can only implore all Drupal folks.

Look at Laravel Livewire, and what they're doing, what concepts can be, can we take, how can we can basically, I mean, Drupal 8, was all us. Standing on the shoulders of the Symfony giants here and I'd taken a lot of the concepts, learning from them, et cetera, and maybe it's time to learn a little bit from Laravel now, because they do a lot of things right right now.

Yeah, it's, we can really profit in the Drupal ecosystem and we still have so many things. going on within Drupal , the way we are way more advanced in, in the whole UI, the whole cycle, the role, the whole dynamic data thing. but there's also lots of things where we can learn and ensure our developers have much better developer experience.

And. It gives that experience and that really, this whole thing just not be painful for building sites.

Preston So : [00:43:21] Well. Very cool. And I'm very excited for one to see what comes out of all of this. I think it's a very exciting, new, day for Drupal. and, we'll see what we'll see what comes out of these, interesting new declarative components and Drupal, I think, we'll see how they come up.

And, I, for one, I'm very excited to start using. actual HTML, like syntax instead of, public includes and all the syntax that we've had to learn. So, I'm, I'm, I'm very excited to keep following this progress and also to, of course, welcome, I, you know, you and others back on the show who are working on this to, to, to talk about this.

And, I know we didn't get to all the topics for today, but we do have a little bit more time to give a bit of an Aside Tag about things that we're working on. So if we could all just for one minute, share a little bit about things that we're working on, shameless plugs, what's going on in our, in our world today.

I'll go first, so I have just started a new monthly newsletter. For all of my subscribers who are interested in exclusive content about things like headless CMS, APIs, voice content, all the things that you know and love for my content on the web, that will now be available also in the form of a monthly newsletter.

I've had a lot of readers and followers ask me how they can get access to not only the content on my website, but also all the content that I produce outside of that realm. So if you're interested, the very first newsletter will be later this month. And, there'll be a monthly newsletter with a lot of great content, and I'll be introducing some exclusive content as well in that newsletter.

And there's going to be all sorts of great content, not only about Drupal and Oracle. But also about some of the exciting front end technologies that we've discussed today. as well as some more interesting, higher level articles about where the CMS is headed and also where digital experiences are headed at large.

So please head to my website and subscribe to my newsletter and you'll get the first one in your inbox later this month. What's going on with Fabian?

Fabian Franz : [00:45:17] Oh, I'm very, very excited that we, we thought a lot about, we want to modernize some very old, they're still in Drupal 7, and they are obviously using the JQuery paradigm and one of them even used Angular 1.

Like six years ago and we wanted to modernize all of that because JQuery is nice and good, but they are more modern ways to, to write JavaScript now and one way it would have been the Vue one time like Laravel again, does a lot of way. It makes it pretty simple. But what I so much dislike is tooling. I don't really want those steps.

I mean, it's one of the reasons why I write PHP. I just write my code. I reload and it has changed. It doesn't need to compile. I don't need to do anything. And even with this automatic compiling, this automatic was hard for me to work with, all of this live reloading, et cetera. Neither with CSS, that's why I like Tailwind, nor with Javascript and I just built steps. I really don't like them. This was what I liked so much about JQuery that you could just. Including JQuery those 300 kilobyte monster, and, but there's a really nice alternative, and it's called Preact plus HTM. Preact is 3.5 kilobytes. And HTM is again, 500 bytes. So you have four kilobytes and you have a full blown React ecosystem. It's completely amazing.

And the nicest thing is you just include them. If HTM all modules, you can use all the modern technologies and you don't need any bill step. You can just use input statements. You can use things and it just works. It's like magic. It's really like magic that the browser market is now here.

They can write modern JavaScript without any tooling, no bother, no nothing. And HTM was using those JavaScript template controls so you can write JSX, but without having to transpire JSX, and this is really magic. The same approach that led HTML users. It's more from the web components world, but that's it.

Preact is, if you have another library, it's even fully comfortable with React, so you can even mix and match web components is blazingly fast. Very, Very little in size and if anyone just wants to sprinkle a little bit of React like take this in that traditional applications replace some JQuery, ultimately remove those 300 hundred, not 50 kilobyte monster from the sides and replaced with some other things, I think Preact is your choice and really check out HTM because it's so cool to write JSX without having to transpire and this is pretty great.

Preston So : [00:48:09] Wonderful. Well, I will definitely want to talk more about your work with both of those projects and your insights there on a future Tag1 Team Talk.

Michael, how about you? What's a new in your world?

Michael Meyers : [00:48:19] June, who works on our team and gets these podcasts and video live showed me a new tool that she's using and it blew my mind. It's one of the coolest things I've seen in a long time. It's called Descript, and it uses AI to create the text, text transcripts and the closed captioning for our audio and video files, which is nothing new. But where it really is exciting is that you can then edit the text to edit your audio and video, and that's super cool. And it also allows real time collaboration in the editing.

Which is clearly near and dear to my heart. We've been a lot of Tag Team Talks on the topic of shared editing, so check it out at descript,

descript.com. If you guys do anything with audio or video, it makes editing such an easy process.

Fabian Franz : [00:49:12] Yeah. The thing that Michael might've told me about that is, for example, if someone is like, yeah, Oh, like all of those full words, and you just can edit them out in the text, the transcribed text, and then they're out in the video audio as well.

This is like that, like the real killer about this idea that Mike brought up. Yeah. Okay.

Preston So : [00:49:35] Well, with that we are out of time and I'm once again, just so we get all those links, the links for my website, Preston.So, and also Descript, descript.com. all the links that we mentioned today related to Laravel, Livewire.

Why are related to Blade X related to all the things that we spoke about today are going to be posted online with this talk. And if you liked this talk, please remember to upvote subscribe, share it with your friends and family with social distancing, of course in place. And of course, check out our past talks on tag1.com/tagteamtalks

We'd love to hear your feedback and topic ideas if you want to have Fabian back on the show for another, a deep exploration of some of the things that he mentioned or if you want to have others on the show that we haven't yet had on the show. Please write to us to tagteamtalks@tag1consulting.com I want to thank my dear friends, Michael and Fabian and today for joining us on the show and see you next time.