Kickstart Your Drupal Build with Sous and Emulsify

SPEAKER:
My name is Brian Goldstein. I'm a technical strategist at Four Kitchens. I am joined by my fabulous and incredibly more talented colleagues, Callin, Laura, and Amanda. Today, we're going to talk about the why and the how of kickstarting your Drupal Build with Sous and Emulsify. What we're going to go over today is, like I said, we're going to start with some of the more theoretical like the why we're doing this and why it solves some of the things that we find most irritating. I'm going to give a very, very brief introduction to the theory undergirding it, which is this idea of component-driven development. And then, like I said, my way more talented colleagues are going to actually step you through an example component development. Two things of a front matter before we get going. First, the slides are up on the session description page on the (UNKNOWN) site. If you want to follow along with the instructions, go ahead and download them. I believe there are PDF. The other thing is if you get stuck on any step, if you're following along or have difficulty with anything, we are having a birds-of-a-feather session.

Please come and join us. It's at 1:45 in one of the BOF rooms. So, I briefly mentioned who we are. For those of you who are not in attendance and are watching this later, Laura Johnson is a senior engineer, Callin Mullaney is also a senior engineer and Amanda is a senior Front End engineer. I'm a technical strategist and a passable Front End engineer. We'll use a lot of terms today. We're going to be throwing them around pretty fast and we won't have a stop and define them each time. But how we're using them today and what they mean in this context are Emulsify is the design system and component library tool that we're using. It is CMS agnostic. It is organized by the atomic design methodology and we're going to talk more about that later and how that fits into everything. And it uses storybook as our front-end workshop to build and test components independent from whatever CMS that you're working in. Sous is our starter kit for Drupal that comes with an Emulsify-based theme. So, if you use Sous, you have Emulsify there to use as well.

Last compound is a library of pre-built components. The component that we're going to be looking at as an example is one of the components that comes in compound. But we're going to give a lot of guidance toward the end of this presentation about best practices when you go to build your own more complicated components. So, let's talk about why we would use these tools in the first place. We all have lots of problems as Drupal devs, Drupal specifically, but like generally it's very complicated to build a website well these days. And what are some of those problems? The biggest one is, is that there's no good answer for all of these problems all the time. One size fits none. Let's say you want to work with higher ed clients. There are distributions out there in the Drupal community, but all of them are pretty bloated. Either they have more functionality than you need and you have to take things out or the front ends are all mess and that's just one vertical. You could look at any vertical and find the same thing.

Workflow Disconnect. Good luck fitting one of those distributions or any other pre-built things with like your CI or CD integrations. Good luck getting your staging environments and your production environments all synced up. Good luck getting your local setup to be smooth and efficient. Probably the hardest thing for me in my role as a technical strategist is getting everybody to call everything by the same name and having a lot of difficulty getting people to use terms not interchangeably to get to use accordion to mean an accordion. I've seen it referred to in one project as expendables, draws, items, labels, lists. And again, none of those are correct. But people and especially people who are non-technical will use them interchangeably. So, getting people simply to use the same naming convention at the same time is a huge problem that most systems don't even try to account for. And last, if you have a system that is really dependent on everybody working together well, it can be very herky-jerky.

It certainly doesn't support agile methodology if you have to hand tickets back and forth between a front-end developer and a back-end developer or a site builder or a content editor. So, having a tool that allows work to progress along independent tracks is a huge, huge benefit. And that is why Sous and Emulsify solves so many problems. I'm going to talk about how they solve those problems right now. It makes minimal assumptions about what you'll need. Obviously, there's enough of a starting point. It comes with most of the modules that we use on every single project. Very common ones, common ones that we run into using a bunch, but we don't try to like overburden you. And on the front end, using Emulsify and Storybook, we give the option of using compound which comes with pre-built components. We don't make a ton of assumptions about the kinds of things that you'll need too. That's all up to you. But we give you a logical starting point and we're going to talk some about like a blank Sous and Emulsify install versus the demo one that we have today.

There is a slight difference there, but my colleagues will talk about that. Workflow support. One of the best things about Sous now and going forward is how it fits in with CI tools like Tugboat, how it fits in with Pantheon, and how it fits in with spinning up multiple environments etc. So, it supports a modern development workflow. Integrating Storybook into Emulsify the way that we have provides a one-stop shop reference for your clients, for your designers, for your front-end and back-end engineers, and your technical strategist architect types like me to all agree on the same name and agree on the same things about that feature. So, it also provides a place to test things independent from the CMS itself, which is a very, very big concern and gets into my last reason why we use these tools in the first place. We can actually have separation of concerns and separation of efforts and that is going to improve accuracy, efficiency, and lets people work on things independent and agile from each other.

Real quick, I want to give a grounding in the theory behind why this all works together, and that's component-driven development. The why is or let's start with defining it. One of the problems we run into, I'm sure that the Drupal shop people in here can sympathize with is Drupal uses a lot of common terms in very specific ways. So, we have to be very air quoty when we say certain words like features or panels or stuff like that. Please note if you hear me say a Drupal term in this slide, I'm referring to it in a general colloquial sense, not the Drupal-specific sense. Basically, component-driven development is our way of looking at a site in terms of its constituent parts. They're air quotes, features, not the Drupal sense, the generic sense. And we do this so that we can make each feature as best as possible. Not every site needs every feature, not every site needs every version of every feature. One of the things we talk a lot about as tech strategists is this idea of simple, lovable, complete as a starting point, and then enhancing for that as it gets more complex for the needs of all.

And so this whole way of building sites is based around this idea that you can look at things as discrete components and then build those things separately well and with high quality. So, that's how these tools all support these things. And then why would we do it this way? Well, I've got a lot of reasons here, and I want to go deep on two of them. The first one says, clarity in user stories, acceptance criteria, and estimation. So, if you think about building out specifications for a site, you've got all your different features and you've got all your different stories for those features, you could write a feature as an eight-point (UNKNOWN). It has a back end, it has a front end, it has authoring experience requirements, etc. You could do it as one ticket and put all those user stories into one ticket and you could write all your acceptance criteria on it and you can say, OK, that's one point ticket and move on to the next feature. Or with component-driven development and with what Emulsifying Sous allow us to do is we can break that into two or three separate tickets that are smaller and easier than to break up user stories, break up acceptance criteria into smaller things, and easier to estimate.

Smaller tickets are easier to estimate. They're also simpler to test, and it makes it possible to include a little bit more nuance in your user stories. So, if your only concerned on a ticket is the front-end stuff or your only concern on the ticket, is the authoring experience or an architecture, you can test for that. And you might say, OK, why would I take a one eight-point ticket and turn it into three three-point tickets? Isn't that going to like cause story point bloat over time? You might argue that. I would argue that it makes each testing smaller, which makes it easier and simpler to do. And that'll increase your velocity over the course of a build. In our experience those things compound. So, you might end up with 100 three-point tickets as opposed to 40 eight-point tickets and net 20 story points over the course of the build. Something like that is really, really important. And again, you're not winning on any one ticket. You're winning over the whole build. So keep that in mind.

Lego complexity is the other one I wanted to talk about. I mentioned atomic design before and Callin can talk about this. Laura and Amanda can talk about this more in their sections. But basically, the idea is, is that atomic design takes a small thing and then builds on top of it. What Lego complexity is, is like taking the next logical step with that, which is if you go to like a Lego store, you can buy a set, get a distribution and it'll have all the pieces you need to build that thing. With this is we're giving you the pick a brick wall. And if you've ever been to the Lego Store, they have this giant wall where you can take these kinds of bricks and those kinds of bricks and those kinds of bricks and combine them in any way. So, we're giving you the best of all worlds with it, which is we allow you to make your own bricks, basically. And that's what Lego complexity really is about, is we give you the ability to build the tiny things, to build the bigger things in any way that you want.

So, this can take that feeling of every site feeling the same and instantly make it a lot more variable. This is something that Callin can show you or talk about from our Smith build right now and the different options that we've built into it. A ton of flexibility for content editors as well. When we do sprint demos now, it is remarkable to see clients' heads basically explode like, oh, I can do that with it. So, I've talked for a long time, probably longer than it actually takes to set up a Sous and Emulsify project. And on that note, I'm going to throw it over to my colleague Laura. Oh, gosh darn it. (CROSSTALK). Oh, shoot. It is this USB. There it goes. Here we go. We're back. Thank you, Brian. Little excitement into the mix. One of the things that I find really cool about Sous as a project at our agency is that not just back-end developers, but front-end developers and technical (UNKNOWN) are all kind of interested in it. I am a back-end developer and also a tech lead, so I'm going to sort of give you my perspective as a tech lead.

So, Sous is our starter project. It installs and configures a set of modules that we're using as the base for most of our projects. And tech leads one of the great things about it is that we've basically with a combination of composer create plus some scripts that we run, we can set up the entire thing with just one command. So, as a tech lead, you know, I can run this one command and it installs and configures all of my modules, installs media components, and I can basically take that entire thing, commit it to a repo, and it's just about ready for devs to start contributing to it. So, here is the command composer create. And so by the way, we have all of these commands listed and the resources at the back of the end of the slide deck, which is linked in the session description. So, if you would like to run it now and follow along, if you have Lando, you can go ahead and run it, give it a try yourself, and yeah. And again, we encourage you to come to the BOF where we're going to sort of do all together kind of wire components from scratch.

So, yeah, so there is the command composer create the name of the repository and project name. And it creates. So, when you run this, you'll see it install the C composer run, it installs all of the modules and then you'll see it run some scripts. So, it creates a new theme based on our Emulsify. The theme is whatever you call your project name, that's what your custom theme is going to be named, and you'll find that in the custom directory. Then we've got some additional commands that build Storybook and the whole thing runs and at the end, it will run (UNKNOWN) and will spit out a link that you can use to log in as the administrative user. And you're ready to go. If you're interested in checking out the scripts that we use to make all of it happen, you can take a look in the composer. We use the composer post create project command and you'll see the scripts listed there and you can check them out in the scripts directory. So, when you first run the first command, that is what you'll see.

The one on the left is what we are basically using as a jumping-off point for new projects. So, they're like, we were looking at the, the, the custom theme that's based on Emulsify is very blank. And so that is where our front-end developers are going to come and create a whole new custom theme. It doesn't have any components in it like when you first set it up. We have a CLI that you can use with compound to either install all of the default content components or you can sort of pick and choose which you want. So, for the purposes of this demo and wiring up a component, we thought it'd be better if we actually had a more developed theme so that when we wire it, it actually looks like something and just this white blank screen. So, we created this lovely theme actually, Callin created it. And so we have another command Lando's Sous demo install that installs some default content. So, it installs some paragraphs and it installs some components from compound and it installs this demo theme.

And so that's basically where we used to jump off from in this demonstration. And now I'm going to pass it over to Amanda to talk about working through an example component. So, we're going to wire a text with media component. And also go over some pointers for how wiring in Drupal with Emulsify works. This component text with media it comes when you... It's one of the default components from compound our component library that we maintain and it's also a paragraph that installs by default with Sous. And this is what it looks like. This is what it will look like when we've wired it to Emulsify. It's a single image and a block of text. The image can be aligned right or left, and that's controlled by a field on the paragraph in Drupal. So, let's get started. Like we said before, you'll want to do Lambo compound install and then that installs the compound library. So, if you do install the compound library, it will give you all these great components to kind of like build off of and alter as needed.

You can also build your own. It's just really nice to not have to create all these things that you use in every website from scratch so it gives you a good place to start. Once you've done that, you can run npm run theme watch and that will start your Storybook instance. Alan. Really quick. Is there a way we can install compound without having Lando on our machines? So, for instance, let's say we have some developers who like to use DDEV for local development or some other kind of local development process. I believe so. So, we set up Lando compound install just to make this simple single command that's easy to read and understand. There's also (UNKNOWN) into your Emulsify theme. You can run the Emulsify CLI command. I think its emulsified system install compound is the component library that we're using. So, this is just a (CROSSTALK). To make it easy for... There are other component libraries out there that (UNKNOWN) is working on. Yale has their own component library and we also in our contribution community check ins for Emulsify once a month, there's some other contributors that are using their own component libraries.

So, we want to be extensible. And these commands are run in the theme directory. The ones that we're showing here don't need to be run from the theme directory. These were kind of simplified just for this presentation. But yeah, like Callin said, Emulsify has a command line interface that you can run all these things from too. And when you run the setup process, it does reference those Emulsify commands as well. So, the output in your CLI, once you run the composer create command will kind of show you all these. But for these purposes, we just want to make some nice, easy commands that you can run from the project room. Great. So yes, once you run your theme watch, then it'll spit out this URL here. You can just visit your local host URL the big red arrow is pointing to and that will show you your Storybook instance. And just another reminder about the BOF today at 1:45 in case you have questions about this whole side of things. So, this is an example of what the Emulsify's Storybook instance would look like.

Right here we've got an example teaser. It's really nice because Storybook comes with these great tools for the front end. There's an accessibility tab which you can see down below and that will tell you right away if you've got any accessibility issues. You don't have to wait till you get to the Drupal side of things to catch those things. You can do it right from Storybook. It also comes with the controls tab. This is something you configure within your component, but it allows for different variations to be created, and then like even the client can toggle between a left and right-aligned image, for example. That's what Brian was talking about when clients are really wowed by what they're seeing and just in Storybook. So yeah, different colors, different layouts, those are a lot of different some of the different options that you can. Oh, and sometimes you can put a little field. There isn't an example in this picture, but you could put a text area where they could type in their own text to replace the text showing in the teaser, for example.

Working in Storybook. So, I've kind of been using Emulsify and Storybook interchangeably. Storybook is just kind of what it's like the workshop that Emulsify is built on top of, and it's organized in the atomic design structure. So, atoms, molecules, organisms built in that like building block methodology. We can use Storybook to build out everything starting from fonts, styles, colors, spacing, breakpoints, and then all the way up to being able to see a full page layout. It will just be like an example of what that will look like once you get to Drupal. So, in this instance, we're just going to be looking at a molecule, kind of a mid-level component and it'll contain a heading, a text, a link and media field. So, each Emulsify component contains a twig template. That's where your markup is. That's where your variables will live. Then you'll also see usually you'll see a Sass and a JavaScript file. Not necessarily JavaScript, but most of the time you'll have its own Sass file. Then there's a yml file.

Sorry, I skipped around there. Switched those two. The yml file will contain your example data. I'll show you an example in a second, but it's not data that's going to be used in the final product. It's just to show your example. And then there's a storyies.js file and that's where a lot of the kind of like puts the whole component together and allows you to declare your different variations. Great. So, this is the text with image twig file. An example of one. So, first, we're declaring the base class text with image. This is going to allow you to kind of with the BEM function just kind of like use it throughout the whole component. Next, we're setting some attributes for the component, like the image position data attribute for the position of the image. So, by default, it sets the left. That's something that you can change in your yml file or once you get to Drupal you'll be able to set that there, class names. And below that we've got our markup content. The heading, we're including a lower-level component, the heading.

And then, you know, those variables that are associated with that element and then the rest of it. You've got our text component is included and then an optional link is included. And then finally the image at the very end there, and that is wrapped with a twig block. And the reason why we do that is because we'll end up completely replacing that with the Drupal image component. You're not going to want to use the path to the image. You want to use the actual full image from Drupal and we'll get to more about why that's important later. And this is the yml file. Like I said, it's these are the variables for example only. It's kind of like just a placeholder content. And the stories.js file is a very simple version of it. You're just declaring the twig file, the yml file, and then naming it, and then putting them all together. There's a lot more that can be done here. Like I showed, you can put your controls and your variables to make it a lot more dynamic once you get to Storybook. And so this is what that looks like in Storybook.

We've got the image on the left, title, text, and the link. So, we got it working in Storybook. The next part is to wire it in Drupal. I'm gonna hand it over to Callin. Cool. Thanks, Amanda. Alright, so let's get Drupal to render that component now that we've built it out in Storybook. So, we're going to go ahead and take a look at what we have in Drupal. So, the content architecture, we want to first verify that that's all in place and ready to go. In this instance we're using Sous relies on paragraphs for our content architecture specifically for components. So, here we have a simple text with image. We name our component in Storybook the same as our paragraphed entity here. And you can see the architecture for it's pretty simple. We have our formatted text fields, we have a media reference field, and then our simple select list for our alignment field that's a simple left and right select list. And then the next step here is we want to take a look at how the managed display options that are for this specific paragraph.

And we want to look at the field outputs that are happening here. You'll notice here that we're hiding all the labels. We say the formatted text field should just display by default. It's a default formatted option. We have our media SC set to render the actual media entity in a specific view mode that we've pre-set up that we want to show for this component specifically. You'll notice that the rendered view mode is set to paragraph text with image. That's just my naming convention that I like to use. I like the set media entity display mode labels to where the entity type and the bundle that I like to use them in. It helps me kind of keep things separated out and know exactly what image or what view mode is used where in the system. But you might have your own naming conventions that you can use. And then lastly, we have our media alignment, which if you remember, was just a simple text select list. For these fields that you might want to use as display options, it's best to use the key value, the key instead of the value.

The value is what gets shown to the user. That can change in a future update pretty easily with just simply changing the configuration. But the key is a bit more stable. It's lowercase, there's no spacing characters in it and it's much harder to change down the line, especially if there's already content in the system. So, here's an example of if we were just to add content to that paragraph, we get kind of a not-great output by default from Drupal. So, we do rely on the core stable nine-core theme, which gives us the bare minimum we need to kind of render markup. But as you'll notice, we have a bunch of empty wrapping divs that don't have a class on them. The paragraph classes are somewhat useful, but they don't follow a BEM architecture and there are other markup in there that just it's hard to style. I could probably style this, but it would make my styling my Sass pretty ugly and probably pretty nested to try and get this working. So, let's wire this up to the component. Actually, before we do that, I want to just show the output to compare the output of what Amanda built previously.

So, you can see here that we do have I don't have a cursor. You can see that we have our BEM functions with text, with image that gets prefixed. We have our data attribute image position being added to the system and then our content section and our image section have nice unique classes using the BEM architecture or BEM class convention, thank you, that makes it easy for styles to be unique and target specific elements without worrying of my styling that I'm writing bleeding into other components that we don't want to affect. Alright. So, here we have our custom theme here. And we have our two directories that we need to worry about when it comes to wiring. So, as I mentioned at the top in Emulsify the components directory, this is our atomic design organizational structure. So, we have our atoms, molecules, and organisms. And that's kind of where that legal complexity that Brian mentioned earlier comes into play where atoms build into molecules, molecules built into organisms. The Drupal template files is probably something if you've done theming in Drupal before, you've seen that service.

It's kind of loosely organized by entity type, although there's some miscellaneous stuff in there as well. This is Stable 9's way that they group them. You can organize your templates any way that you really want within Drupal still pick it up as long as they're named properly. And as well as when it comes to wiring, you might not want to wire every single template in the system. You might just want to target your paragraphs and wire them that way, or nodes or other custom entities. So, what we're going to do is we're going to wire this up. So, in our molecules folder, we have our text with image, that twig file that Amanda showed earlier. And then below that, we have our unique paragraph that we've built or that comes with Sous. So, our paragraph--text-with-media. So, it allows us to target our entity and then our entity bundle there based on the naming convention of that template. We're not doing any special template suggestions here to get that. That's just a standard output that you can get through Drupal's twig suggestions and their services that (UNKNOWN) you able.

So, you'll notice here in the first line we have a shorthand namespace molecules app molecules section. With Sous, we are pre-installing the components module. This allows us to namespace our components so it makes just referencing and embedding and including our components a bit easier and easier to read. So, instead of saying embed back out of this directory, go into components 02-molecules, and then dive into it, we can just namespace it to app molecules and reference our component that way. With that embed, we are then using the width property there to map our variables to the component. So, we have our text with image underscore text that gets mapped directly to our text, our formatted text field, and then we have our text with image position variable that gets mapped to the key value output of the media alignment field. You'll notice with that section there I am diving into that field to get the actual string value because that's what our component expects. If I just reference content.field media alignment, you would then get the field template being injected into your component.

So, you really just want to get the string value there. And again, because we're targeting the key, we're getting the value all lowercase, no spacing characters and that's unlikely to change in future updates with configuration. And then below that, we have our block that we're replacing and there we are actually outputting the entire field output from Drupal. We're not targeting the image URL or anything like that. We're just saying spit out that whole output. We always use responsive image styles in setting up a media output and what Drupal outputs with that responsive image style module is pretty solid markup and we tend to use that just to save a lot of time without making the need to create our own responsive image component. So, highly recommend you just use that output there. And once we do that we have a fully wired component. So, here we're looking at our Drupal front end. This is the demo front end here and we have now our markup. Instead of having all those extra divs with no classes and a lot of extra markups, we have our BEM function and our attributes, and all of our unique classes getting injected into our rendered from Drupal.

But now our image is from the media library from Drupal, and this is the text that the content editor actually edits within Drupal itself. So, with that, so this was an example of a really simple component. It was a discrete object. We have an image, we have a block of text, and we have ways to adjust the display of that. But because, you know, websites often involve other complex components, I'll give you some tips here on how to handle some things like nesting or looping or other ways that you might have multiple entities affecting a single component. So, just to cover some of the twig names and functions that we are using, the blocks I mentioned earlier, these are replaceable chunks within your twig file. This is where you just say, I want to just output the content of this field and replace the image completely with what we were using from our yml file within Emulsify. Includes are probably the simplest way to reference another twig file. It just does include your component and you can do simple variable mapping with that.

Embeds are the most flexible and probably the most used. If you are doing wiring, not only can you do the variable mapping with the width property, but you can also replace blocks with embeds. And then extends are more of a parent-child template type of relationship generally used when you use an extend, you're essentially saying completely reuse this other component or other template and just replace the specific blocks of it. I tend to use these more for page layouts where I want to replace the entire header section with a specific component or something like that. So, when it comes to looping, this is something I see as a common problem for people when they start kind of getting into Emulsify and wiring templates. So, it's very tempting to treat your more complex component like a discrete object when splitting it up into multiple templates. It actually makes it much easier not only to read but to also manage. So, it's like I said, it's tempting to, you know, embed your component and then embed within an embed within and embed.

And it gets really complex if you start doing that. It's possible. I've seen it. I've done it myself, but it makes it really, really hard. And then you have this gigantic twig template file that you cannot affect anything because it's very brittle. It's looping through loops. So, in this example, this small example, here we have an accordion component, accordion component, we have our main heading, and then we have our accordion items. The accordion items are a reference field to another paragraph we call the accordion item that we want to basically loop through. Now, I could, instead of replacing the block and rendering the entire field, I could embed within an embed and try and draw out those specific fields from that sub-entity. But you'll see here that we just have a seven-line template file just for the accordion itself. And we're just saying, hey, reference field, just render out those accordion items. And if we look at why I'm doing that, what we've done here is we have this intermediate step where we have the content accordion item field prints its own field template, the field template by default from stable nine already does the looping for you.

So, if it's a multi-value field, which in this case it would be, it's going to loop for you and we're just going to let it do its thing. So, we're going to print the whole field value. And then for the paragraph accordion item entity in a separate template, we just map the partial accordion item and that's where we have our variables that we can just do a simple include and map them according to the heading that always shows that the user clicks and then the content that gets revealed once you click. So, instead of dealing with loops and adding force and creating a file that's probably 30 or 40 lines long, we have two simple files that are less than six lines each. So, a couple of things here is that it can be time-consuming to reinvent and wire all instances of markup. I mentioned this before with a responsive image module. The markup that that module gives you is pretty solid. I mentioned you can create your own responsive image component, but we all have limited time. We have limited budgets.

Rely on the output that some of these modules give you, where it seems to work really well. So, as I mentioned, media, we're just going to print our media as we see fit. Some other examples of where you'd want to rely on Drupal to just output the markup you want to use are contextual menus, forms, web forms, and views expose forms. They spit out something that's nice, that's easy to work with. And then if possible, create a unique template form and wrap them in some BEM class functions there just to make your styling easier. But it's not completely necessary. And then just to wrap up here, we have just some good guidance on kind of how to handle some of this stuff. Drupal's Render arrays-of-doom always do that in the Drupal template first and send clean formatted data to your components. This makes logic in your components much easier. They don't have to handle like date formatting or something like that within your twig file. You let Drupal do the date formatting for you and you send that clean output to your component.

Use Drupal Responsive image system. Let Drupal render forms and form inputs and use view modes wherever possible to create unique twig templates that you can do your wiring for. And Brian, want to wrap us up here? Yeah. Thank you, everyone. We are good on time, so there's plenty of time for questions or stepping through other examples. If you want to go to the next couple of slides, we do have a couple of appendices here. The first one is commands used today, so we've got your command to get a working Drupal site up and running, to install the default content and demo theme compound components in Storybooks. Oh, sorry, I'm going to pass in front of everybody. Yep. Recording. Yeah. Sorry. We are good on time. We have plenty of time for questions. And like I was saying, going through some of these appendices real fast, we have all the commands that we used today. If you are joining us or watching this later, please go to the session page, download the notes. I know we've said that a bunch, but all of this is there for you as well.

We also have further resources and documentation. We've been working with Sous and Emulsify for several years now and there are a lot of notes and things out there that will help you get up to speed really fast if this is your first project or first time using it. Please check out the actual sites and documentations. If you want more information about Storybook itself, they've got great documentation and tutorials on their site. Of course, you can always check out our new site fourkitchens.com. We also have a couple of good reference articles and tutorials that we have found helpful. So, that is the final slide in the deck. We have nothing else to cover on that ground. We covered a ton of ground today. And once again, thank you to my fabulous and amazingly talented colleagues for stepping through some of those technical details. Does anyone have any questions that we could answer while we're here? Do you recommend learning all of these things at once altogether (INAUDIBLE) or should we just learn about them (INAUDIBLE)?

Oh, that's a good question. I think I have to... Oh, sorry. Alan reminds me to repeat the question for recording sake. This is a lot to learn. Do you recommend learning it sequentially in any particular order all at once or like individually? And my default answer would be whatever suits your learning style. If you are the kind of person who can absorb it that way by inhaling all of it at once, go for it. If you need to be more peaceful, go with it. I know with our latest release of Sous, we have tried to build it so that it will be Drupal 10 upgradable and more of a starter kit and less of a distribution. So, there will be time for you to learn these things. And my personal recommendation would be just start building something with it and see what comes up as a personal thing. If anybody else from my group wants to jump in with a more technical answer, by all means. So, it depends on kind of, you know, your profession and kind of where you want to focus. If you don't want to have Drupal in the mix, you want to focus in on just front-end development, you can install Emulsify without Sous, without Drupal install.

And that's using this Emulsify CLI. Check out the site for how to run that. And you can install (UNKNOWN) Emulsify. Just work on that. Have your Storybook install and build your components that way and then worry about integrating it into Drupal or WordPress or Gatsby later on. So, it is a platform agnostic. The one that we have pre-generated with Sous is a Drupal-specific theme that has like your dot info file, your dot libraries file. So, if you want to have Drupal in the mix, I'd suggest using that composer create command and you have a default blank install of Drupal ready to go to build whatever project you want. But yeah, if you're just a front-end person, just use Emulsify CLI and you can get things working that way. Yeah, I was just going to say, if you're more of a back-end person and you want to know, like as a back-end developer, how do I actually wire Drupal data into a component? The exercise that we plan on doing at the BOF is in our Sous demo theme, we have all of the templates wired already.

So, as an exercise, we were going to take the (UNKNOWN) media component Drupal template and just throw it in the trash and start basically wiring from scratch, which is a good exercise for back-end developers to try and figure out how to do that. Are you guys providing an easy way out of Sous? Because I know the challenge for distribution is that once you buy into it, you are stuck. I think if we learn anything from (UNKNOWN) is that (INAUDIBLE) you're not going to support it anymore. Those projects will probably have to see what they do because changing themes is high enough to (INAUDIBLE). Do you want me to talk? OK. Yeah. Repeat the question. Yeah. So, the question was, is Sous easy to back out of because distributions are kind of locked into your installation and are very hard to manage as distributions can become out of date? And then you have a dependency problem that's happening there. So, Sous originally was a distribution and we ran into those exact same problems where we never meant it to really be something that we wanted to continuously update.

We always want it to be something that it's a ground-level thing that we start with and we build whatever project you need from. Sous recently had a 5.0 update which removes the installation profile completely, and we are just installing default configuration during the Drupal install process. So, there is no Sous dependency, there's nothing distribution in your install anymore. From Drupal's perspective, it's just a standard installation so there's no other dependencies. Everything is in your composer file. There's no, you know, bundle of unlike in a distribution where you have that as a dependency which has other dependencies, all your modules are just in your composer file. Yep. Do you use this on all of your projects or is there a certain type of project complexity or front-end elements that this is a good fit for? Yeah, we use Emulsify on all our projects. Sous in the past because we've had distributions, we've decided to strategically not use it. But with this new version, this is the plan going forward is that for every site, whether it's higher education or media publishing, we can use this going forward because of that dependency of the distribution is now gone.

And it's flexible enough and it makes little to no assumptions on what site you're going to build for, but it gives you a ground level of what to use. So, if you want to build a blog or if you want to build a media publishing site or you have a college site, that college multi-site that you need to do, you can build with this as a ground, as a starting point. Anything else? I have another question. Tell me, does this help at all with collaboration with your designers? And more specifically, have you examined Figma into Storybook integration or anything? Yeah. So, our compound component library by default makes no assumptions on styling. So, when you get it, it's basically like solid markup, solid accessibility, and you build on top of that. We are working on not a sequel to compound, but a sister project called the UI Kit that works with design tokens. So, the designer designs in Figma, they export their design tokens, which I think comes out as a JSON file. They send that to a developer, we import it in there and we have all our colors, spacing variables, everything that matches what Figma outputs.

So, when we theme as front enders, we. Just say use that design token. I don't care what the value is, just use whatever that design token is and then if the designer changes it down the line, we just re-import and it updates those values. I think you had a (INAUDIBLE). Is that your point? OK. That's good. Yeah. So, that's coming down the line. That's something that we're currently working in and our director, our creative director is kind of is really pushing for that internal project to get that ready for a (UNKNOWN) presentation. Callin, may I? Yeah. One additional point on that. Yes, our designers and creative team go into the Storybook instance to do their testing so you can look at the accessibility plug-in like Amanda mentioned. You can also look at the responsive nature of the Storybook instance itself to test does this work on mobile, does this work on tablet, etc, etc. So yes, it does help enhance that cross-discipline collaboration. Do you guys have like a roadmap of other things coming down the pipeline?

The question was, do we have a roadmap? Nothing that's well defined. But we do have the concept of recipes that we're working with now. Currently, Sous relies on paragraphs as our content architecture for components, but there's a big push for layout builder, custom blocks, and other ways besides paragraphs. Our recipe concept that we're currently prototyping happens. You can basically like include a recipe that has active configuration that bundles everything together. So, if we have a recipe that's for media publishing, we can make very opinionated functionality and configuration within that recipe, that's an optional install on top of Sous. The same goes with multi-sites or whatever type of site. So, we want to build Sous as the platform that's generic enough to fit anywhere but then have these recipes that then streamline that process for something that's a bit more vertically integrated. Is that the Drupal community (UNKNOWN) concept. Yes. Yeah, we have a couple of developers that are... You have so many overloaded terms (CROSSTALK).

Yeah, that's right. We're running out of the terms. Yes. Yeah. It's funny how it fits with Four Kitchen's recipes. No, we talked about this years ago and a couple of our developers internally have been contributing to that effort as well. And part of this prototyping is can we make that core patch work in a solid way that then pushes the project along. So yeah, it is the same thing. Yeah. Outside developer helping us migrate data from (UNKNOWN) seven to nine and now we are applying this Emulsify for us. During the migration paragraph, content was kind of difficult. We had to manually recreate this for this. Currently, we are using Emulsify for (UNKNOWN) for the paragraph data migration (INAUDIBLE), will we have any problem in the future? I don't think so. That's a great question. How... I can say to you, generally migrating paragraphs is very tricky. A lot of times people just fall back (INAUDIBLE) doing it. So, I missed the presentation, so I don't know if (INAUDIBLE) just in general.

Paragraph migration is usually (UNKNOWN). So, the question was about migration, and specifically migrating from paragraphs, it is very difficult. Emulsify does not solve for that currently. Sous does not solve for that currently. I don't think that's going to be part of the spec. But yeah, there's another web chef here by the name of Michael Lutz. If you find him, he is a bit of our in-house migration expert and he might be able to shed more light on that specific question. We are doing a D7's panels to D9 paragraphs migration right now, and that is very, very tricky and coming with a lot of issues too. So, we feel your pain. We have no direct aid for that just yet. Thank you. We only have a few more minutes. If anybody has any questions or other concerns, please come join us at our Birds-of-a-Feather session today at 1:45. From that, lunch is about next. So, do we want to head out for an early lunch? Alright. Thank you so much.