 Oh Hello and welcome people are still shooting in a little bit. So But we start kind of like there's a boring things So we'll Talk a little bit My name is Fabian France And I'm here today and I'm so excited to be here again at Drupal con speaking to you and What I have today for you. I'm so excited about I've talked everyone I talked to right now and so Even if people are coming in still we'll start They would then need to watch recording later. It's a packed session. So there we go Components everywhere. We are bridging the gap between the back and then the front and it's a vision for Drupal core and First of all a huge hello to you all in Amsterdam Welcome to Drupal con. Welcome to my talk as said, I'm excited and This is so cool a bit First of all, please click away the cookie burner except our terms and conditions No It's targeted mainly as a beginner session However, everyone should be able to learn something because there's some never-before-seen concepts. I've searched all the internet The session description had react, but I've decided in the end for we because it's a little bit easier to understand But everything is kind of front-end technology Agnostic you can implement it with whatever you want. It's just that that turned out to be the easiest one There's working patterns and code that you could be implementing today. However It's important that a lot lot lot lot lot of this work and still needs to be done There's some basic color codes Unfortunately, it's not completely Super everything but if you see those colors, you can be pretty sure what it means The Drupal or the back end. It's blue Drupal's blue. Obviously we react that components. I've made green Whenever we are talking about real-time technologies, they will be pink If there's something that's important that attention please it's yellow and if something doesn't work I don't like it or it's a problem. Then we make it right But let's start about you. Who of you has used Drupal 5.0 and lower? Wow quite some veterans Drupal 6 and Ah, wow cool Drupal 7 and Drupal 8 Nice Drupal 9 someone Oh, yeah, and Drupal 42 any time travelers here too bad So About me. I'm Fabian France. I'm a senior architect performance and team lead attack one consulting It's best company I've ever worked on. I'm a Drupal 7 branch maintainer. I Got tricked into Drupal 8 core before feature freeze and afterwards I've helped hundreds of contributors that actually made the real work of making it possible I've architect the Drupal 8 caching system together with families. I've brought you placeholders and big pipe We've talked a lot about that in previous Drupal cons and This is my next big thing One of the challenges I faced when I was looking in all this decoupled Drupal and all the things is that no JS Single-side rendering is not the answer Overall decoupled Drupal. It works great React, Vue, Svaldo, whatever they all have server-side rendering But there's a problem because why should I mix this PHP and node and not just directly use a node-based CMS and It's something we hear more and more in like This PHP world we are kind of starting to lose market share there To the node thing and we are also seen by a lot of people like from the React Community I've worked with a lot of like react developers in the past months pure react developers like the hardcore front-enders and Really great people and we are seen at that thing from the past One example for example When we were like, yeah, we'll just do our HTML in the database and they were like, oh, but what about security? What about that and we've solved that problem longer than react exists with our input for output filtering anyway Also, not every application is suited for the fully decoupled way. There's still a lot of benefit to building Drupal things Traditionally like you've ever done with page request and everything So the goal of that thing is that no node.js is needed We have mostly PHP a little bit of JavaScript not like all JavaScript and and little PHP And we still have interactive apps and also to make Drupal front and finally easy and fun The other motivation I had was And I've been I mean everyone's saying web components are the future than others are saying now It's not they're not the future. They're totally not the future there. I bet but components web components They are not the future. They are here now. They're here at Drupal con. There was one training about it There are several sessions about it. There are several buffs about it Components pattern lab all of that They're here, but we actually need them in core We don't need them somewhere here and there etc Because when I've learned one thing about my long history with Drupal It was that if you really want to make change it needs to begin at the core and there is where you can make the huge impact on things Like with trick. Yes, we could have a contract trick But it would never have had the impact that trick within core would have his auto escape and all the nice features Unfortunately the same component library as can know where so far that was kind of where I stopped at previous Drupal cons I kind of worked with seamless along the way again again at the contribution days and we brainstormed and we checked Etc. But in the end kind of would win others etc. I found this team component library in core There wasn't a real benefit. There was nothing that would like say that this investment would be worse it that Why should be doing that the same system works great trick works great? It was not different enough from what we have to Say that we should be doing it So what's a web component at a very basic level web components are custom elements that mean you just define like menu item or You don't find section you define article you define my date picker you define whatever you want It's just custom HTML tag. It's your HTML tag. You are using it and it's defined in JavaScript a Component consists usually of HTML CSS and JavaScript it is a template So you have a template then you have CSS. It's usually scoped to The component itself so it shouldn't affect anything else on the page and then you have JavaScript It's also scoped so it should only affect the component and not the nav bar which would be bad Components are overall configured via props and object attributes Props means Yeah, you all know it image source whatever Very simple here. We have our custom menu item. We are just putting I want to reference a section one and Now I have a prop The problem is if I want to put a prop in there and I have an object Then what JavaScript puts out is Bracket object bracket and that's not so useful so there's another way to work with web components and that is to assign like an Attribute to the object itself and then I can put more data in it And I don't really like that in my opinion whenever we have something that's so complex It needs to come from a data tree. It shouldn't be a property It's no longer configuration. It's data and if it's configuration something is wrong with the design of it a Pure men's component especially for all of those familiar as stupid six seven and eight Because we can build like it like a pure men's component like right now we take a trick template Then we take the Drupal behaviors and if you ever written a Drupal behavior, you know, there are some best practices around it Some are not followed some are followed. But basically what you ensure is You have like usually you have an configuration. It's a generic configuration for for example a photo slideshow Then you have instance configuration this photo slideshow has three columns Then you have dot ones. I only want to apply this once and then you have the context with the scope Which is Drupal JavaScript Ajax specific, but so basically I've kind of Was too long for the slide here, but I've written that up sometime and we could completely abstract that all out the scoping Etc. I just have a class that now said similar to web component The CSS yes, it sucks, but just putting in dot menu item before everything You can scope it Obviously all the front end technologies make this much nicer, etc And then we could also be investing in that technology. However, we have something that works now It's promise component, but we have all that mean so what's not a component what's not a component is this and So there you have a diff we have a class we have a Lee we have a diff and yeah, it's kind of a Drupal outputs right now And actually it's diff diff diff diff diff It's modern nightmare So what's really cool about component trees and one of the things that really excites me is they are so nice to read and So nice to to write also It's like it gives the fun back into into seeming like that and that I can just write HTML code And I've write my components directly as HTML I don't have to learn some syntax for including have a function available or not available I have a component library and I use those components and I think also that's a huge appeal of all those Technologies that are here out in the front end. So but don't we have said already like we have says when the API We have says when a tree we have the assume hooks. We have the types, etc. Thanks, Moosh and In a way, we have But in a way, we don't and to understand a little why it's not enough We have to like take a little history lesson So because troopers render tree in a sense it is like a virtual dome, but it has one floor. You've never thought about I Bet you all just got to the session because of that link bait So in Drupal 6 what we had was HTML seam item list was the template had all the logic in it and it's not pure It was early rendering. So HTML then we would be putting the HTML and some other HTML, etc At 5 in Drupal 6 that changed thanks to all miles Merlin of cows many will still know him also views recently by chance talked with him about it and he was like, yeah Pure templates that was why I introduced pre-process in it. And I was like, ah That was it was about I've been a seamstress to maintain us in a long time here, but well understanding history helps So now our templates are pure. They have no business logic They have just a presentation the pre-process is preparing the data and then it's displayed, but the problem is we still had the early rendering so That changed in Drupal 7 because we want really give contract more possibility of changing the render tree later So and that was actually inspired by form API. So we're building a render tree We are rendering that tree and this looks kind of like this Seem item list items, but the templates are not poor But huge advantage. It can be modified till the end. There's also this render. So We had to put a render whenever it's a render array and not a render when it was not a render array so there was a little thing and then trick came and It says one thing I would regret today is not getting rid of render arrays at that point, but instead supporting them Because the templates are not pure But they seem pure because it can just for outside by left But internally it's still doing the same render call like before because we kept those render arrays Then big pipe and placeholders dynamic page cache came along and we said we need to render even later to improve performance we Take the static and the dynamic things we put them out together And then we first render the static things later We render the other things and then we found out there's objects in the render tree That's because they could be modified or even did that was comments for a big problem So we introduced lazy builders safe. No dependencies on the current page request usually They are really great the callback lots of data and they would be suitable or is a Ajax, etc So lazy builders are really nice and clean in that they would be a good stepping stone for implementing that So we found a pattern here. We tried to render later and later to improve performance So in Drupal 42 will directly run inside your hat. Just you wait so Drupal 9 10 11 let's run it even later. We just run it on the client, you know We have said already decoupled Drupal does that kind of no, we don't have that And the reason is and that's the key and it's one key sense of this whole presentation We need to decouple Drupal within the back end. We need to decouple Drupal within the back end We need to decouple Drupal within the back end. Just repeat after me. We need to decouple Drupal within the back end And the reason is because the render tree is so complex We have data. We have configuration. We have presentation. We have templates. We have preprocessed. We have functions We have even access control in that and that's all in one tree and that's really How do you decouple that? So Let's take a look under the hood of how like a typical react component like would work in that We have like a react thing So usually a root component here how it works Usually you have like a function when the component is mounted that means you have your single page application The component gets mounted in it That means it starts to be rendered in it and then before it gets mounted it gets the data from somewhere So for example, I have my I want my favorite books in a block So I would say yeah this dot favorites would be fetch the favorites from some API GraphQL JSON API All of those nice API first things and then a typical view template would be looking like There's a list for four item and favorites and then I just pay for example the item name Drupal looks a little bit different So we have the same for each node Loop then we built a render array like all of that with our favorites here we are seeming the favorites differently and In the end we return an item list another render array We put the items in it and that's kind of a Drupal thing does things So Drupal is here mixing the data and stayed with the presentation actually However react and we just get it from some data source And that's a very very important point because inside we are getting here is that the data decoupling of that thing is the key to success here So because if you take our same block like a standard Drupal block and we just give it a data function And that returns from some store from entity manager from loading from whatever from calling Google Docs Doesn't matter where data comes from but it returns your favorites and then in render We're using that data from the favorites and then we export the same data for example in Drupal settings Now we have achieved That we have the same data can drive the front end at the back end because the same data is now suddenly available At the front end and at the back end so Just to recap that again, and you could be implementing this today. It's so cool We have a data generator. We have a source of the data that can be custom code It could be suitable view. It could even be calling Jason API beyond internal Call back within core like a sub request even could be graph to our rest whatever you want Really, whatever you want. It could even in some way come from the render tree Was too complex for the talk, but I have the architecture We exported to Drupal settings and now we have the same data that's driving the front end It is driving the back end We still need one template for the front end We still need one template for the back end. However We have the same data we can Render the same markup as I said you can implement that today You just need to decouple your data and so that's so important How we still have a little bit problem because I really don't want to write the same template twice So we have trick we have trick we have trick trick components to rescue And yes, actually there are. There are several different libraries. There's trick.js, trick.js and Tring The one trick.js is server compiled So it's PHP code on the server compiling to JavaScript or transpiling as you would like and Then those are sent to the client and the client can use them Then there's trick.js which purely trick client-based JavaScript works a note and then there's Tring which is was They also said it was even made for a Drupal 8 in that Because he wanted to use templates on the client trick templates directly and Tring has a huge advantage that it passes the trick test suite. So it's probably the most stable Technology out there. That's here and sure Can it work for pure components? It can totally work for the core trick templates We have right now. It's a little bit difficult However, we still have some problems because front-end work is not just about rendering Sure trick template we render etc. But we also have reactivity. We have virtual DOM diffing What does reactivity mean reactivity means? You click something and something happens somewhere else and Virtual DOM diffing will come to that in a moment So do we really need to reinvent react, etc. Do we need to write another view? That's just truly will whatever no We don't fortunately We need to do a little deep dive into JSX and the Crete element functions because there's one thing and I've worked on this two years ago and I failed Because trick renders to a string and at that time I was thinking that was a show blocker There was a road blocker that I could never get over that it would completely destroy my dream of This talk here. It turns out that was not true Because react and view etc. They render to a virtual dome and the virtual dome actually allows you a very very great experience you have like like span you have a counter and Only what changes is re-rendered and that's so so Practical because it allows you to not have to re-render all those bands and everything that's behind it Only the text of the counter will be updated and this gives the best user experience possible and that's Drupal's Ajax old replace elements not suitable because what replace all the spans as well and This java JSX is actually transpired to Crete element span Crete text element hello world, so it's creating this tree internally That's also one of the reasons why we angular etc. Use a syntax that adds the directory to the dome nodes And that only allows like like placeholders within Properties of that because it's a dome language trick is no dome language trick can do everything it can output C++ code It can output JavaScript code. It can output SQL. It's easy, but it's a problem for us here Because we was really simple to pass into a virtual dome tree so tricking virtual domano friends and I even tried that That's where I failed like and then I had this example You can do that in trick. It's valid It will output valid HTML, but it's almost impossible to compile that into a virtual dome before actually doing it So we have to do dome parsing. It's straight off, but it's okay And we also need a component tree because we need to actually know that there's a block in the sidebar There's an entity in the sidebar because we want to be able to re-render that everything Fortunately, we especially has an inline template parser So any HTML using the runtime a JS can be converted into virtual dome at runtime And it turns out who doesn't care if you first render to a string and then convert it into a virtual dome It works. It really needs the virtual dome for the diffing of things. It doesn't need it for and for finding the components It doesn't need it for actually rendering the things and Using the props and that So what we can do now we have a trick template with context We turn it into a string of HTML on components and that we turn to a virtual dome so we get all the benefits of the front end technologies and Yep, just create a virtual dome converter for things could be as easy as in HTML because it's pure HTML we have and Put that into react whatever change it to create element should all work It's a performance penalty. Yes, it is But it's still good enough for the 95% case You might be wondering if Fabian is like this performance person and now he tells us performance not important Performance is very important. However, if I have the choice between writing every template twice And only writing 5% of the templates that are performance critical twice And it might probably still even be much much faster than just rendering Ajax from the server I'll take this trade off for being able to at least do the 95% case So what about the back end? Again a key thing we need as a PHP community even a web components custom element shim and PHP and It's pretty simple even we do it like we we pass the dome We would just as a components in the library we search for the widgets that custom elements we pass slot content We run in the component and a p-wake match Pretty simple can even do that. We are doing that for big pipe like I'm very very simple dome parsing It's it's not a huge performance penalty in that Works really cool. So we have success. We have server-side rendering by Drupal as a go So how does it work? Everything has a representation, so we have a template menu item and this gives this output and I had a hard time understanding this kind of this two words that are converted in each other So what I found much easier was when it was in the web components world suddenly and I was like, oh, yeah It's just the inner part of that menu item. It's just how the browser is rendering He doesn't know about a menu item. He just know about what's inside it Kind of like that in in web components. It's a shadow dome So it's hidden from your user and you keep the nice markup shadow dome is optional But we can also just do debug output other Drupal core and that's actually not a bad idea because it really shows you where That markup came from but instead of like this was including the strict template It's just showing kind of this or just seem hook, etc So we ran a trick component we expose the data and template via settings We just that we component automatically for each custom saying the mounts root view components and We get the data for the component other set rule for settings And that's basically it Now we have kind of all we need to do it Almost service at rendering and we we need to either add a special thing that this thing was already server rendered Or we just use a special parameter, but now we are there Maybe not No, actually, we are not there yet because oh my god, sorry Oh my god The reactivity it does not work because hey, I changed the Drupal settings favorite Nothing happens But why and the reason is that when we are mounting this component in view it makes a copy This that favorites equals Drupal settings favorites here. We have a copy so whenever we is using this internally It looks that if you were changing the favorites of that component It would be all working well but in this case It doesn't because we just know nothing about Drupal settings Fortunately, that's a totally solved problem in the front end world already It was so fear flicks weeks, whatever you just use a store and the store is really cool because You just use item in this dot store dot favorites And then the Ajax command would be as simple as store set state favorites are new favorites and that's it and Obviously implementation details will differ between different stores, whatever I really like flexible JS the most but Whatever you want to use you can use a store and now the nice thing is now that we have a store We can update it reactivity works We can also put that store to be real-time and offline first real-time and offline first means the client has a copy of the data It's there it connects to a store the store to a real-time system. There's yjs. There's fire by base. There's gun dot eco It's the name of such library and What happens here is the remote state changes and because our store is informed about Changes that are happening for example on the Google fire base thing here. It's synchronized automatically So what we can do now is we don't even need to output the Ajax anymore We can just write to the real-time store directly We just write the new favorites of the user to fire base and The front end and all his devices the mobile the desktop the iPad The presentation screen everywhere it changes automatically and I think people more and more expect this kind of real-time experiences But Drupal so far had no answer no on even getting there decoupled of course a little bit more But not with our traditional model and really want to bridge that gap also into the real-time sayings If you want to try that use fire base. It's a it's commercial. It costs a lot, but it's just some plus to use Free and open source there would be a real-time collaborative editor with yjs That you can try you really should give it a try It's like Google Docs in your CMS if you integrate it. It's fantastic We talked about it about in our tech team talk deep dive in the real-time collaborative editing solutions You learn about a lot about real-time things as well here And I'll also be doing a future team talk about this rather topic and all the technical details. I had to admit here So what are the next steps I? Can definitely share a lot more technical details. This is not just this presentation This is actually a solid architecture with many many things sort through of how we can get there There was just not enough time for this presentation because I want to give you a chance to ask Some questions too So maybe an idea would be everyone that would be interested in front end and still here They are to meet up on Thursday to discuss all of that We could also be doing a barf if there's enough interest in that you can hit me up on Twitter We can do it in contributes slack whatever we'll connect somehow and together Let's create the best front-end experience ever And now comes kind of the vision part of all the nice things We can do if we start to implement even a little bit of that because what we had here in Drupal conlos Angeles is The unicorn dream and the dream it was Morton's dream was he went to build a Drupal site with just one index HTML trick And this components index kind of finally makes this possible and thanks to slots There was a missing piece kind of all these years and web components have so slots we have so slots Even trick has so slots slots as blocks, but starting to understand them It's really solving this because here Morton can put his block and all the other things that someone configured in the UI They are still output Morton is not overriding it. He's extending it He's putting it to the header of the sidebar and Morton is also overriding this This title of the block very simple. He just put slot title overriding it boom done and This is it was closed Deplicated inline template. It was an issue I really should be careful It was an issue where I Tried to Do kind of like this just with pure trick. It gets so complicated. I Had to give I managed to do it, but it was never core ready But this could be core ready You could create plugins for modern editors which just use configure those custom elements CK and have five pros more quip No more filter convert display image ID render HTML You directly output the configured component and Drupal will do the rest Big pipe placeholders with default content could be finally easy. It would be so simple You just write block you tape Drupal placeholder big pipe puts a default content and once the content arrives It's there don't even need need all those JavaScript render on the saying just our traditional big pipe It could be so enhanced by syntax the performance could be improved dramatically if you're using a store for more things You just update the real-time key value store even if even if it's just on Drupal Whatever you output it via settings and the data driven mindset makes us so much easier to think about in that You export the data the templates to for example S3. You could load it on a completely different Micro-side my company nav It's your component is lots of data from somewhere it works and the company nav is always active on all sides We're using that component because it glorts it from the remote it keeps all the nice things like contextual links as part of the data tree There was a huge problem with decoupled implementations always like contextual links. We are losing so much The preview live preview all of those things It also makes progressive decoupling as an easier than ever. There's all session here Drupal corn about Progressive decoupling this view that we might check out It's completely front and technology agnostic without reinventing the wheel So we don't have to reinvent the wheel We don't have to write another view we can really just just just use it and last but not least This would make single page applications possible without writing a single line of JavaScript What do you think? Thank you very much Please like subscribe follow me in Twitter and hit the bell. I mean rate my session I'm Fabian France Fabian talk one consulting comm if you have questions, please ask Yeah basically the question was I've Said a lot had a lot of new examples And the question was if it's possible to use any fronted technology to implement this pattern the answer is yes You can You might need to do some work like for Putting it into their virtual dome differential dome whatever Your technology uses but in general is possible It it's completely front and technology agnostic as long as you have a render function that you can customize yourself But all the bigger front end things have a next question. Yeah So the question was what needs to happen in Drupal core to make this possible One of the things we could be starting at is to convert more of things into lazy builders Then the other thing is Because once we have like no more dependencies in our render tree It would be very very more simple to convert that into a component tree. The other thing is Basically, we need like a hook and we can totally start that in contrapp That's after each rendering of the trick template is going through and Parting the dome for a custom components and then for each component We are finding like the menu item We would just call seem menu item like and then we would be going to the next component like that So the main difference is basically why it before you would be having like include menu item or include menu Or whatever with those bars in the trick syntax, you would know just writing HTML So it kind of even maps a little bit one-to-one in that That you can do it. It's just the huge problem with include is That's and where we kind of failed and just give some real quick historic data Amber was like coming to us I think was also LA and they were like hey We have this data tree and then we have this component tree and we put that together like that and we were like hey That's great. We want to do that as well. We start with the templates and we were like How do we render the children now etc? So for example, you take a simple template like The entity template and it displays an entity internally and it's just a rendering like that For displaying this entity and we know it's a render array which has just their hashtag entity So instead of doing kind of what we do we can extract the properties And there's a lot of like how also pattern lab etc already works and we can just say entity and have this Component entity and then we put the data in and that's kind of one thing But what we need to be sure is that in the end every template we have or the output with the components still intact not replaced with Includes it's like a recursive tree in itself once we have that we can make a single page application Okay, universal data store Little bit quick about that, but the store basically was the store pattern means you have a store somewhere And you can think about it as a key value store You so you put data in it some key and you get it out. It's a key for example as simple as that user one favorite That's my key That's slightly relate to caching because in essence the favorites of the user the data of that whenever it changes We need to change the store. So I favored something else. I changed the store. So it's a permanent cache Because it's always accurate Reflecting what the favorites of my user are Now I have two possibilities. I can output those favorites this in Drupal settings and that's the kind of Normal way how you would be getting the initial data into the store and then if I have an update I would set the state the universal store is different There they're there we can just imagine. This is Google and this is firebase so in this case with Google and firebase We would be Writing the user favorites over there and the front end would also be getting it from over there And whenever it changes they inform us that this has changed now they inform us And all our devices are synchronized so Drupal in this case would indeed be directly writing to firebase It would not be communicating with the front end But it would just communicate with its door and that alone is also a pretty powerful pattern and with yjs It would be possible to implement it even peer-to-peer Completely open source We out of time but One last question. Yeah, the thing is it's never too late now And it needs to be a new API it really needs to be a new API It needs to be completely pack what compatible to everything we have it can't replace anything It can't change anything that's not how Drupal works anymore It is a new API and if there's sufficient interest in the community and everyone has switched to it Then at one point in 10 11 whatever etc We could think about Deprecating the render trees etc that that's kind of how this thing works to slowly deprecate things in it Replace it with something else But make it till the next major version keep it around so no one is forced to do it Okay We are out of time Thank you very much. Please join us for the contribution Opportunities and rate the session and thanks to my wife for making the nice illustrations late at night