 Yeah, so today I'm going to talk about single file components. This is a module that I made, I think earlier this year and it's about componentizing the front end, which I think there's been a lot of presentations about already. Before we start talking about it, we really have to start talking about Vue.js. This is a front end framework, kind of in the same class as Angular or React, if you haven't heard of it, and it provides a concept called single file components. And what this is, is it's a .vue file, which you can see on the right, that includes a template with their template language, some JavaScript, and some CSS, and somehow magically you can include this component in Vue and it renders everything and styles it and it just works. So this is exciting and I wanted to bring this concept to Drupal, but before we do that, we have to think about what Drupal component really is. So we have a template and language in Drupal 8 and 9 called twig. So there's a twig template. There's some CSS. There's a JavaScript that's global. So this is just like a raw JavaScript. And there's JavaScript inside Drupal behaviors. So this is when you've seen Drupal behaviors attach. And then there's PHP. You don't think of PHP as being a front end component, but in Drupal it really is. We have form alters. We have pre-process functions. We have theme hooks. We have so much that happens in PHP. So this is where single file components come in. It tries to take all of these parts that make up one Drupal thing and put it in one file. So we'll jump right into an example. This is a single file component on the left. Just like you have .view files in ViewJS, you have a .sfc file in single file components. This includes a template, CSS, JavaScript and PHP. And just like view, you can use it by including it in another template. So you use normal twig includes with the special syntax, you know, pre-fixing it with sfc-dash in the name of the file. And then somehow it makes sure that CSS is attached and it makes sure everything renders correctly. So this is pretty crazy and there's a lot of glue and magic to make this happen. So just to kind of briefly go through it, these .sfc files are discovered and derive single file component plugins. Just like you have a layout YAML file or a lot of other things in YAML like migrations that derive plugins, it's the same thing, but these are just .sfc files. Then it sees that you have the style tag in there and it'll create library definition automatically that includes that CSS file. Then when you actually render the twig template by including it in another twig template, there's a custom twig loader that'll make sure everything's set up and the right single file component is initialized and it'll use its template. Because we know there's CSS, we also need an attached library called to make sure that you actually get that library when you render your template. And then when that template is rendered and when the assets are collected, it'll actually create a real CSS file where that content of the style tag is output to. So it's not doing inline styles, it's actually outputting a real file. So let's actually quantify this. On the left is a single file component that basically provides a very simple block. You can see the twig template accepts some name. And on the bottom there's some PHP that I'll explain really soon that basically provides a block. So this is a style block with a twig template that can be overridden and it's 12 lines of code. To do this in vanilla Drupal, you need a lot of moving parts. You need a block class. You need to hook theme definition. That's to make including the twig template easier and also allows overrides. You need a library definition, you need a CSS file, and you need an actual twig file with the template and that attached library call. So just comparing, so it's 12 lines of code versus 33 lines of code, which actually isn't that huge, but the point is to edit everything about this block, you would have to go to five files to figure that out. So the sales pitch is really you can edit five or six files or you could edit just one. So we're going to dive into features. These are a lot of slides that go through basically everything the module does. So hold on. So first let's revisit that previous example where I said a block was created. So this is something special you can do for single file components that makes it really easy to quickly provide a block, a layout or a field formatter, and you do it by editing the plugin definition for the single file component right inside it with PHP. So it's kind of weird and foreign it's probably like not a good looking part of the module, but in just three lines of code, I can tell single file components hey I want to block. And here's the part of that block definition that I want changed. So anything you can do when you define a block like in that block annotation for a class you can do here right now it's just the admin label, but you may choose to provide all sorts of different stuff in the definition. You can also provide pages quickly you know we don't really think of components as pages in Drupal because we have so many ways to make pages that are done through the UI. So in most front end frameworks components are everything it's your top level app all the way down to pages all the way down to text. So you can do this in single file components by using a controller that I provide in the base module. You can see it up in this top thing this component controller. What it does is it takes in a component ID, it'll render that at a given path, you can see the path is hello slash name. You can actually pass the parameters the request parameters and symphony down to your component. So if you somehow had this setup and you visited hello slash Sam, my single file component would say hello Sam. This is great I know people love using views, but if you're making a site quickly, or you know that a page is never going to change. This is great even for listings. You can also make the includes little easier you know way back in that first example I said you know you have to do include SFC dash dash and your plugin ID. That's quite long, and you may want to provide better DX for your front end developers so you can provide aliases, which are alternative names to give your component. So in this example you can include this with that full SFC thing. You can do it with a simple name you can do it with slashes kind of mimicking nesting, or you could just have that like single easy name. This is really nice because it makes includes easier but this does kind of break part of component design because you know if you were using a ton of libraries of single file components, you know many of them would have conflicting names so you just want to use this. In a good way and just be aware of what you're doing single file components can also provide forms. I know this is again like a lot of PHP to see at once but if you think about it. If you're providing a block with a single file component pretty common use case for a block is to have a form where you can configure things. So single file components abstracts that into these four methods called build context form there's validate and submit. And this lets you essentially edit the twig context in a form, you don't have to worry about how this is used. So you see that even though this could be used as a block there's nothing that says block anywhere it just knows. Okay, this is some form and providing other people to configure my twig context. So this example is kind of complicated but basically it's a component that rolls a die. And you can determine how many sites that dice has so you could have a d20 block or a d6 block or whatever you want. And those are dnd terms or something but 20 sided dice or six sided dice so also if you like a lot of the features I've shown but you don't like the idea of doing CSS and JavaScript in one file if you like really like your workflow. You can point always point to a separate Drupal library. So of course you could do this yourself and then write attached library yourself and your template. But you can also quickly provide this little inline library definition that will get used in your component. So this is nice so you don't have to maintain a library the ammo file and you can kind of couple the CSS used by this component with the actual template. There's also this funny concept of defining JavaScript JavaScript quickly inside single file components so if you've used Drupal and you've defined a Drupal behavior. You know that there's a lot of boilerplate code to do that you need to wait for the document to load. You need to have Drupal behaviors attached and you're supposed to have detached but I don't think most of us do that. And inside that often you also have to either use the context pass to it or jQuery wants to make sure that it's not reattaching these behaviors. So all of what I just said makes no sense to most front end developers and absolutely no sense to anyone outside Drupal. It's like the most Drupal part of our JavaScript ecosystem. So what I've tried to do is provide these nice helper attributes to your script tags. So you can see this as data type attach what this will do is it'll wrap your code with all of that Drupal gunk useful gunk. And you can just focus on using the this context which will be the root element of your component. So to me this looks a little weird, but this is way easier than doing all of that boilerplate every time. Yep. And just to make it clear what's going on here's a similar example so at the top. Here's some JavaScript that would be wrapped by this behavior and then this is the final output. You can see all the way up to this line so four lines of code are just Drupal isms that you probably don't care about or ever change. So another thing you can do in single file components in this definition thing is you can override other twig templates which is actually overriding theme hooks. This is useful if you want everything in a single file component and you don't want to have like any theme twig files. I know that's a little like far fetched but I'm sure there's a use case. You can also arbitrarily override other theme hooks, and this works, but I'll kind of say that it's it also breaks this component driven design because you're saying, here's a component that cannot be used abstractly it only is probably going to be used in this use case for this template override. Of course in reality like things are perfect and a lot of times you just need to override one template but that's just something to consider when you use this it's kind of like a hammer that you may not need. And also I know that all the examples I've given so far use vanilla CSS and JavaScript. But again in reality that's not how a lot of our builds work anymore we use ES six we use imports we use SAS we have a crazy build chain. And while that doesn't work perfectly with single file components, you can make it work with things like gulp. In this module I've provided an example of gulp file that will basically take a source SFC file, parse out these things inside the script tag and the SAS and everything transpile them and then pop them out into a production SFC file. So you can do this and it works. I found that whenever use this module it's actually is kind of fun to go back to vanilla JavaScript because you just get to scope down the behavior so small. Yeah, like I said a lot of us aren't there where we're using front end frameworks and such. On that same line of thought. While there's no features that make this specifically good for single file components I think the module works really well with front end frameworks. You know this concept of packaging everything in a small ways is common for the front end now. And I'm excited to see what people do with it like integrations with view and react. So the first example on the right is using alpine JS. It's kind of newer just like tailwind the ideas that you can define how a component or how HTML interacts with JavaScript with attributes so without writing like an actual script tag, you can add attributes like data initializing data for this or state at click, you know a click call back x text, you know a bit of text update when the data updates or the state updates. This is what alpine JS does so it works well so those examples are also in a module way earlier I talked about how SFC files end up deriving component plugins. This is true. And the back end of that are behind the curtain is that there's real classes that are powering everything. This example looks kind of surprising because you're seeing like twig and CSS inside PHP, but it's doing exactly the same thing as SFC files so if you want you can define single file components in a PHP class. So I think the use case for this is, I don't know people that really love PHP or people that want to unit test things or maybe you have a component that's more about like entity queries and forms than it is about actual twig. This would be useful. So it's kind of an ugly layer to show you finally finishing up features. One thing I've focused on with single file components is making it really easy to override them. There's real Drupal libraries being generated, you can use libraries extend or libraries override in your theme. You can also override the template. There's theme hooks that are created for every single file component so they're easy to override. If you're using classes you can extend the class or use traits. And also their plugins so anything you can do crazy with plugins if you thought of how much you have hacked the block plugin system you can do the same stuff with SFC files. The other thing is that this is kind of hard to do with other component solutions. It's hard to say here's a component library, you can override anything you want. A lot of times they do things like there may be a block inside the twig template you can use or there's some way to extend it but you're not using the kind of Drupal isms you're used to. So I've tried to make that easy. I've been testing that that has been proved out by me in the module so a lot of times with component libraries you're doing your testing all in JavaScript are all like really abstract from Drupal, which is great but a lot of what this module is about is bringing more to Drupal and more traditional Drupal than not. So you can totally use normal kernel tests you can use unit tests. You can use the functional JavaScript tests to test components. I won't go into these examples but know that they all use traits that I provide in the module. So you can have 100% test coverage in Drupal of all your components. And that also means you have access to everything Drupal has you have access to the container. You can do crazy Drupal twig stuff without thinking of abstracting that outside of Drupal so it's useful. You can only test components, just like storybook, but definitely not as good as storybook. I provide a sub module called SFC dev, which has this crazy UI you see on the right that basically lets you select any component, any single file component you have. You can render it. You can change the twig that includes it so you can change what context is passed to it, and you can mess with the form if it provides a form. I'll give you a good example of why forms are abstracted out from blocks and layouts, because you never know why someone is configuring your component. So it's kind of a level higher. So when I talk about this, a lot of people ask me how is this different from whatever project. And I don't like this in open source I think competition is okay for driving you but it's a little unhealthy so I know that I did not make this module to compete with anything or replace anything. I did it just for fun, like most of my projects, but I'll go into it anyway. So the biggest differentiator is there's no build step. You can install the module, enable it, make and dot SFC file and rebuild cache and you can use it right away. You don't have to know anything about build steps or transpiling or anything about structure, you just make it in any components folder of any module or theme networks. You can extend them we already talked about that but this is a really cool thing that not every project does it's really clear how you extend single file components. You can use them as blocks field formers for matters and layouts and just like three lines of code. So that's awesome. Actually probably more for layouts and field for matters but blocks at least three lines of code. So testing happens in triple we went over that but I like this a lot. It's kind of hard to think about how your components work outside of the context of your site. So this kind of brings it back home. And of course there's one file. So I know this is kind of like a gimmick like I had the sales pitch slide but it is really nice to have everything in one file, someone asks, how do I change anything about this hero. It's hero.sfc like it couldn't be more clear. Don't say it in that condescending way and they can edit it, you know, so. So yeah, we're almost done. So this is my like, catch my breath break and we're good on time. The last thoughts before I'm done is that the module has almost 100% test coverage I kind of nerded out and tried to test everything. So it's very stable it doesn't mean there's not gaps, or things I haven't thought of but the module is very stable, I think. Another thing is it doesn't support scoped styles. What this is in Vue.js is it's a thing where you can say the style tag is scoped. So all the selectors in it are going to be prefixed with something that's unique to my component. I can't explain it any better. It's a weird thing in view to me and it could be weird or useful in Drupal. So if you want it, let me know and I can probably make it work. And that's it. Thanks so much for watching. I'm on Github and I also have a website Mortensen coffee and everything on this website is styled with single file components. So even the full pages like listings of my blogs or art or whatever so you can go to Mortensen coffee slash components and see how the tool can really be used and yeah. So I should have had this here but the module is called single file components or SFC. So just enable SFC and see how you like it. So that's it. We can take questions I'll stop sharing so actually read chat I just have one screen on the setup so if you said anything I've actually missed it also. Yep. Yeah, thank thank the Lord that you've had audio okay. Yeah if there's any questions let me know this was a short session. So I think technically we have something like 15 minutes but I'm one thing I was supposed to tell you about what's next so while people think of questions or don't want to ask questions I'm going to look that up. So you don't get to see these slides because I'm on my laptop and my setup I was going to use is not working but what's coming up next is at three so you have quite a long break. If there's not any questions so at three there's a session on creating complex field widgets. There's one on maximizing composer. That sounds vague but exciting. So you're upgrading your site to triple nine and building websites that protect user privacy that sounds exciting I'm on the security team so I'd like to see that and then at 245 so kind of sitting here 20 minutes. There's going to be a coffee break in the expo hall sponsored by chapter three. So now you're all caught up. And thanks everyone. We're going to like count to 30 in my head and then end it but thanks so much.