Brightspot front-end training webinar

image of man and laptop in office setting
Requires Login
0:00 / 0:00
Video Companion
Brightspot front-end training webinar

Looking to learn more about handlebars and front-end engineering using Brightspot? Start with this training, led by our world-class team of experts.

Click here to download a copy of the front-end training deck.


Speaker 1: the bright spot in Speaker 2: front of training, I think everybody's here. Great. Um If you guys have questions throughout this training um you can go ahead and use, there's a should be a questions panel in the like the webinar area um where you can ask questions uh instead of uh trying to unmute and ask questions and sort of interrupt if you guys can either through the chat or through that questions panel um ask questions. Um Then as as I see them, I'll lead, they're sort of depending on like if it's exactly in the fortune I'm going over or a little bit later, I'll either stop and go over those questions and and try to answer those uh specifically or some sort of at the end, I'll go through those questions and answer them as well but I think that's the that's the best way to ask specific questions. Um So yeah let's uh so for our agenda gonna go over, this is meant to be sort of a front and overview. I'm not gonna go super into depth into each section, but more provide a general sort of cliff notes around front and development um here are bright spot and show how our front end out of the box, um the bundle that comes with our front end, how that is structured, how the code is a little bit organized inside of there, what the different components are to get the, get our site to render um and then go through um some of the ways that we develop and some of the concepts around front end development. Um So we'll start off by going over like the front and stack and the responsibilities. Um We're gonna like responsibilities of what front end development here. Um Bright spot actually means um go over what we call the roots style guide um and our view system uh and how front end interacts with that. Talked a little about a little bit about our style guide application, which is an application that we use to to basically do our local development. I'll talk over what the front and bundle means um a little bit a ways back. We used to call that the theme but we kind of renamed it as the front and bundle is that made a little bit more sense. Um We'll talk about what that's comprised of. Um We'll go through our handlebars structure, which is our primary renderers of html. We'll talk a little bit about how javascript gets in there and makes their site interactive talk about styling uh in our bundle and how that's organized um and talk through uh some of the Jason and our and the front end and how that's used for um showing examples of how the stop the CMS would would work. And also talk about how Jason is used for configuration, whether it's configuration of the style guide application itself or whether it's used for configuration of inside the CMS. Um And lastly we'll go over a small code example of of making a new style of a content type and kind of dive in just a little bit into the code and uh and and working in uh inside the battle. Um so to start off with the overview, um what is front end? Really mean? A bright spot. Um So for us from and development is everything you'd sort of expect as a friend and developer um where it's dealing with the html dealing with handlebars and a template in language styling it via CSS and creating javascript to make the site interactive, which is sort of traditional front end. Um but in addition, um it also includes some controls to help um actually create the views which is create the date. Um or so I started to model the data a little bit behind what you see on the site. And it also allows, we also have the ability to incorporate publishing features into bright spot into the CMS. Um and that's something that we're going to talk about. It's something that's pretty important because with this we're able to give editors um the option of styling certain content types. And also we have the ability to add um fields into the CMS that can be used for styling um and for adding certain things such as uh some styling elements that just background colors or or things we call these front end fields, but it's basically the ability for us to add editorial features into the CMS without influencing the actual data and the data model. Um so it's a pretty powerful tool. Um so our front end stack and what we use, as far as technologies we use Jason um for configuration. Again whether it's configuration of the style guide application or whether it's configuration of uh these these front end fields and and these things we add into the CMS. Um and we also use Jason um for the schemas for the views. Um we use handlebars as our renderers for html template ng um we use less as our CSS processor for styling. Um We write all of our javascript with es six syntax um and then we use some transpiring uh depending on what browsers we support, we'll get into that later. Um We use web pack as the module bundler. Um we use yarn to automate our workflow. Um and node is uh used to run the style guide application primarily. Um We've got this application that we call the style guide and I'll get into talking about that um and that runs on node. So let's talk about the roots style guy. Um so the Roots style guide um we call it um the route um as it used to live sort of in the root of the of the whole repo and we actually moved it down a level, we still call it the Root style guide but it's really sort of the glue between the back end and the front end of the site. Um Again, like I said, it originally lived in the project root, hence the name, but it's now located in the front end style guide folder. Um Some older projects still have it in the route though. Um What we do inside of this root style guide uh is we specify the views, which is basically what you see the data that you see when you view the website. Um and those are collections of fields, it's a it's a Jason schema um and then each view that we have which is a um if you divide a site into all the different content types, uh different pieces of content. Each one of those is a view um and each one of those views requires adjacent file in the in the handlebar file. The handlebar file is empty. It's really a renderers hook, um for that view to specify which render is to be used, um and then creating each one of these views results in a java interface for the back end developers to implement. Um so let me try to pull up like this. Uh sorry, on a okay, trying to figure out what a good way to um I think this will nicely take over and show it here. Um so this is the root style guide itself, like we said, it lives in the front end uh folder under root style guide and what this contains is it contains the views for every single one of these, every single of the content types we have. Um So for example, um an article would be a good content type and for an article page it contains a Jason file that specifies all the data that an article page is going to have. Um We use certain patterns such as includes to be able to include other Jason files to sort of create larger configuration files without having to repeat data all over the place. Um But nevertheless the these uh Jason files create the view and then it has an empty handlebar renderers which is hooked in through the template uh template key. Um and that is the render that is uh going to be used for that particular view. Um So as front end developers um we create that Jason schema and the fields as that is the data that we need to show on the site. Um so when we look at a mock up we can decide what data is in that mock up and what uh type of data are we going to need to to to show that particular mock up on the site. Um And then with the back end uh Doves do is they do all the data modeling, they create this these actual modules and the entry fields inside the CMS. And they create these view models that actually place that data into the views for us and then the contract between the front end and the back end is that Jason on file, is that actually creates that view? Um that's the data that we as a front end developer said that we need um and the view is auto generated off that scheme that Jason schema that we create and then that way the back end developers know what data they need to provide to us, um how that, how they do that and how they provide that data. Um it's sort of up to the business most of the time, it comes in from the CMS because the back end developers create these data fields in the CMS such as maybe an art, like an article title or an article lead. Um but some of the time it could come from some of the back end api it can be magic. That's the kind of stuff that you're going to get into tomorrow in the back end training when we're talking about data modeling, talk about uh dealing with these uh with these modules in the CMS. Um But again, what we as friend and developers worried about is just the view itself and the data that comes from these Jason files because that's the data that we um figured out that we need um to to show on the site. Um So next uh is we're gonna talk about the style guide application. So the roots style guide again is sort of the it's that folder structure that defines all these views. Um but the style guide application that we have um is this this no Js application um that runs locally and it processes uh example, Jason view files that we create um via our handlebar renderers, uh to actually simulate what's happening into the CMS data injury and simulate the rendering that's happening on the web. Um Well that's not like that's all. God application um uses a dead version of dev environment of web pack to compile our javascript and CSS and since it's using the exact same code and build systems that the real site does, it's just doing that locally in a deV environment. Um it allows us to work locally, um it allows us to see our work instantly and we have trust that the same exact code will work correctly once it's deployed, um we still uh go ahead and uh we can deploy our code uh two QA and go ahead and check stuff there versus just 1000% trusting the work locally because we always want to check it with the real CMS and the real site. Um but essentially the Style guide application is a simulation of the CMS that runs locally via node. And again, it allows us to, allows for very fast local development um because we can edit our handlebar files, we can edit, edit our renderers, um We can provide different examples um of this uh of the Jason views and we can render all those locally and we can see what's happening um and that allows us and it's all doing that real time where when you make the changes to handlebars, um the same thing, when you make your changes to javascript, it auto compiles the javascript that auto compiles our CSS um so it allows us to work very fast in our local environment um and doesn't require the front end developers to um have to run a local instance of the entire CMS um and then try to compile and deploy code every time that we make a change um because again, we're stimulating what is really happening with the CMS by creating these Jason examples and uh and having this application run on top of that. Yeah. Um so next up we're gonna talk a little bit about the front end bundle and um what we call a front end bundle, so as I said before we used to call um this the theme um and then we sort of realized that it's really, it's a, it's a bundle of things and so calling it a front and bundle made a little bit more sense as I think the word theme can be a little bit confusing because for it can mean many different things to many different people um as far as whether it's different from and developers think of a theme of something else or whether the business thinks of a theme, that's something that's not. So a bundle was a lot more of a specific way of, of calling these things um and the bundle is really the whole front end of the site, um it is primarily what we work with this front end developers and it contains um all of the handlebars uh to do that, which are the r html renderers. Um it contains all the javascript for site interactivity. Um it connects, it contains the styling which is CSS built from less from the styling of the site. Um it has any static assets that we might want, um whether it can be like Suggs, some icons that we might be using or whether the static image assets that we want to use um on the, on the front end of the site but that we don't want in the CMS um and it also has a bunch of Jason um which is the configuration for again, these uh these front end fields, which might be um some extra fields that we, as front end developers want to add into the CMS for certain content types and certain styles of content types and it also contains um these uh these examples that we, that I was just talking about which are basically simulated data in the CMS, um or sorry, simulations of data in the CMS um as well, so, um we're gonna go through and uh dive into each one of these um uh each one of these things that are in this bundle and talk a little bit more in depth about how we work with each one of these things and and exactly what they do um in the bundle. Um So to kind of start off the top handlebars, we use handlebars as our template ng engine uh to render html um handlebars as nice as it provides a fairly strong separation between uh template ng styles and javascript rather than sort of having everything together. Um and for content driven um sort of static and air quotes website. Um It's a very good template in language. Um Well it's defined as a logical s template in language. Um but even with that um we found that providing some comparison helpers and some other type of helpers allows us to in composition of templates and it does allow us to put to bake a little bit of business logic into these templates. Um Whereas while you kind of want to go logic less for a template language and lots of business logic should be built into the view model. Um We we feel that some some logic inside of templates just really helps us out. Um And then we've got a number of comparison helpers, some logical helpers, some math helpers um that we have created um that I'll get into here in a minute. Um And then we also have an option to create your own helpers via javascript if you need to um and those will be run um in the when you use those um the local style application uses them and also um when you make these um when the web application is doing the rendering, it also will be able to use those helpers. Um We've got documentation that I linked to right here, which has a comprehensive collection of these helpers and also has documentation on how to create your own. Um But what I'm gonna do is I'm gonna talk through a few of them here that are sort of our most used ones um and ones that I find we find the most helpful and also talk through a couple that are really important as there are core um piece of functionality for our for a handlebar files. Um so we've added some uh simple helpers that are not in handlebars by default for doing some comparison and some logic. Um We have this uh equal helper, a greater than and less than and and and and your um and these shouldn't be really used to create really robust logic, like um well sometimes they could be used for something like string comparisons and things like that. Um but really what they're great for is moving through item arrays with some logic or some conditional rendering. Um and I've got a great example of one here um that I like, let me pull this up here. Um There we go. Sorry, this is trying to figure out how to show this code nicely without like re going over this presentation here. Um So um this is a great example for um of going through and items are right here in a particular, a particular list. Um So a list content type for us is a page list is the list of page promos, which are just kind of a collection of uh titles, descriptions and links, particularly for different particular pages. And a list happens to be an array of items. And using uh these helpers here, we can uh for example, die like do something different with the first item in the array and using our greatest greater than and less than helpers here. Um We can say that, you know, for Array for items in that array that are, you know, one, we might want to do something Else. And then for again, for like other items for 5678 items in that array, we might want to do something else. Um and this is a great use case for these particular helpers without these helpers, I think it would be a lot more difficult to do something like this in handlebars and it's not uh you know, baked in super business logic, but it's really just a good a good way to kind of go through and do some stuff inside of an array. Um We also have um a pretty important setter and getter helper that we create and this allows us to pass values from parents to Children templates. Um and this is very useful for um could reuse and allowing us to reuse a lot of the same uh templates because we might have a child template uh that we might want to use or we might want to have like a particular template that we might want to use and it gets a piece of data. Um and then we might want to have a number of different templates use it and be able to set different variables, two different meanings. Um It were we primarily use this and a lot on image sizing um where we might want to um have, well we have a child template that is just a generic image renderers that just renders a generic image. Um But then we don't know what image size we might want to render and we don't want to bake in an image sides. So we use the setter set and get uh to be able to push to to be able to set image sizes on parent templates um and then be able to get those on the child template and and uh basically, you know, pull that data from that variable. Um There are 2-2 more important templates, I'm sorry, helpers um that we really use mostly for template reuse. Um and this is the include helper and the rendered helper. Um The include helper. Um which if you look through the out of the box, front end bundle. Um It's used everywhere. um and it literally includes another template within a template and it passes in the current context and this is our main tool for supporting uh template reuse. Um This allows us um to create a little snippets of um of handlebars that are very useful all over the place and um you know, have those in one place and just include them throughout a large number of of handlebar files. Um and first is just repeating code over and over and over again. Um So I can I'll show an example of this uh right here um where um we have, you know, I was talking about the page promo module which is um a promotable which is uh amount of data which is a title and description, let's say a link. Um and a particular page promo um you know, they have very much the same data schema, they just have some different looks between them. So we use this include helper um that for every iteration and every style variation of a particular promo, we don't have to rewrite the same code. So we use these include helpers everywhere. So for example, a promo title is a great example of this um where we have this um promo title which actually renders the promo title um It in itself uses uh the link as it includes and passes some data to that. So it's a it continues that sort of re use concepts, so we really have one handlebar that handles a link. Um and then the page promo title um is able to include that and pass its own data to render a link inside of itself and then each iteration of this page promo of each style of this page promo module, you can then include the page promo title and using this pattern. Um We've got some really really nice code reuse that lets us uh write some neat uh working neat small modular handlebar files instead of just repeating the same exact code over and over and over and over again in every single file. Um And then um we have um this other concept of uh called uh sorry, this other helper called render um which is this contextual rendering concept. Um and that concept allows us to render a specific style of a template. Um And what I mean by that is that whenever a great example of this um let's see. Uh Sorry. Uh A great example of this is when you want to um when you want to render a particular, if you have a list of promotable of promos and you want to render a a certain style variation of a promo inside of a list. Um This contextual rendering concept allows you to do that. Um Oh, so um you'll see this throughout our code base as well. Um But again, both of these helpers are um primarily used for for template reuse again rather than um very hard coded hard coding things and reusing the same code over and over and over again. Um We also have a helper that we've created um and that is our primary tool um for dealing with image sizing. Um and that is the resize helper. Um What it is is a directive to receive a specifically resized image uh from dims and this can be used um and it's mostly used along with the setter and getter that I was talking about earlier um to allow for um again sort of code reuse and um contextual image sizing. And the way that you'll see this used right here in this example is we have an image, a single image handlebar render that we use to render basically every image on the site. Um And it uses uh this resize helper to resize an image. Um but what you'll see is that it uses um this get um to get the image size um which uh and then it actually uses an additional helper that we have that's called the fallback, which if that gets um is a null um it'll fall back to a certain vary to a certain value. Um So with this statement um we can resize our image uh to whatever a particular parents specified via the center and if that never happened, it just renders a large image. Um And and that um or I guess it pulls a large image from dims in order to render that. Um and you'll see like for example, one of our page promo modules um uses the set helper. Um and then it sets an image size of a large square because this particular module, you know, has a large square image versus a certain aspect ratio. That because it wants that certain aspect here show it will use the center. And then um you'll see here we actually um go back to that include helper um to go down sort of the that code reuse pattern where we include um this page promo media um help this page from the media handlebar file, which just creates a sort of html structure which every page promo uses. Uh And then you'll see it actually just renders the media in here. Um The media is an image which uses the image handlebar Ender, which then ends up going through here. Uh this get um gets the set from this from the parent and allows you to render a large square image um using this whole entire pattern. Um And again, if you skip that getter, if you skip that set, this would just render you a large image. Um So again, this way we don't have to, you know, you put this image tag and have It in 80,000 places in our code base because we can just use includes to do that. Um And then this resize Albert is uh it takes care of the imagery sizing. Um so uh that uh those are and that there are more helpers that we use in handlebars. Um but those are very we we use a lot of the default handlebar renderers and all that documentation is on the handlebars website, so I didn't want to get into the very um generic like each and with and just, you know, if statements that are um that are included in uh in just generic handlebars because those are all documented and handlebars website. Um So yeah, by no means are the our our custom helpers the only ones we use um those are just ones that we found to be um uh we we we we found that we needed to sort of add to the handlebars helper um default set to make our template in language a little bit better. Um so now that we've, you know, we've used handlebars here to to render some html on the site. Um so now on top of that, um what we use javascript for mostly is to making the site um you know interactive. Um We are a we mostly work with content driven websites which can be more defined as like a let's say, a static site and you know out of the box, what we offer in bright spot um is a like a static sort of sight in the sense that it is uh statically rendered html. Um where then javascript comes over the top and makes that site interactive. Um And for our javascript we use es six um Written javascript, it's a mixture of classes and custom elements. Um We use Babel to trance file our javascript into versions of javascript um into that for browsers that we need to support. Um We use browser list R. C. Um to make that distinction of wood browsers we want to support. Um But this way, you know, if we need to support some older school browsers for a particular older site, we can sort of specify that in battle will take care of transpiring our modern javascript into super old school stuff but if we don't have that um then you know we can specify modern browsers and they will receive more modern javascript. Um We use the web pack to package our javascript. Um uh What we have a combined javascript file as well as chunks. Um We do some dynamic loading of javascript of web pack chunks out of the box and I'll show an example of that in a minute. Um But mostly a lot of times we work with depending on how much javascript and depending on how um how large the javascript of a particular site is, we could have a single javascript package with just some dynamic loading for some of the big stuff or we could split that up into different javascript packages um four different portions of the site. Um Really the answer to that is. It's sort of it's very much depends on um a particular site its needs and how much Js it needs. Um But like I said, I think in general we work with a single package of javascript with some dynamic, a little bit chunks um for some individual large individual javascript files. Um So we I would say mostly use uh javascript custom elements, um we use those to bind the javascript to the dom um for um we feel that for most sort of content driven put in quotes sort of static sites that are not single page applications, if you will um there is no need for having a full javascript framework that loads on each page or trying to get uh super fancy with like dealing with trying to hold state and fully Ajax in future pages and things like that. Um So there is no need to to hold state and page state or deal with views. Um so that way, a full javascript framework that handles all of that for you is not necessary. Um but again, this um this allows us to use our javascript to make the site um more interactive and enhance the html, that's their versus using the javascript for full site rendering now um if you are working with a full page application um you can absolutely use that um with bright spot and there is a graph QL endpoint um where you can get all of the data that is in bright spot and you can use an entire javascript framework um to to work with bright spot um to pull that data um and then completely do all of the renderings of the javascript, whether it's a react app or you know, insert any other javascript framework here kind of um kind of setup um tomorrow there will be a little bit more conversation on the graph QL portion. Um but I figured that this um I'm not going to get into that really with the front end training because here we really are focusing on um sort of the out of the box uh frame the front end setup uh in bright spot and not really all the different kind of custom ways you can work with it or um really um when you create a react app where you create an entire front end application um a lot a lot of that is not going to be dependent on Bright spot is going to be dependent on how your site instead of and how you want that to be set up and then it's just going to use Bright spot to retrieve data from so um that I'm not that's why we're not going to get into that much in today's training um but again, uh to jump back into this um we use javascript to make the site like an html site more interactive and enhance the html um an example of a custom element um that I want to just like show real quick is our uh is something like a carousel. Um and writing some like writing a custom element that comes in over the top, and, you know, creates a carousel out of html, that we pre render. So we've got a handlebar file um for a carousel um that renders a number of slides. Um It uses include uh to use this little uh sub template to uh to deal with each slide, and it creates a custom element to create a bright spot carousel. Um And then we've got a javascript custom element or javascript file for that, Um which uses ES ES six syntax to import uh like a throttling utility. Um And this particular um custom element um uses a dynamic import off lickety um which is a, you know, fairly heavyweight piece of javascript that we might not want to um load on every page that doesn't have a carousel. Um So using this uh isn't connected callback along with an await import allows us to do um allows basically went back to chunk that piece of javascript for flicking out and allows us to dynamically load that when we need it. Um And then we use the connected callback to um as our hook into the dom. Um and this way we can just interact with our portion of the page um that, you know, is our custom element, which happens to be that carousel. Um So we can, you know deal with some event listeners to like wait for the page to load because you want to, that's probably the best practice to deal with things like carousel. We might want to uh resize or re deal with this carousel when uh um you know like the browser's resides. So we use our throttle helper to help with that. Um And then you know, again we've this is just basically um it's kind of standard, simple. Um It's simple javascript but again the pattern of using custom elements to bind to the dom you'll see throughout the bright spot, front end code base um as that's our primary tool for um triggering javascript to load. Um Okay, so um next we're going to get into um styling a little bit. Um so um we use um uh uh less as our CSS pre processor. Um There's no real like super rhyme or reason why we use less over sass I think it's just something that a lot of us, a lot of us here we're familiar with. Um but if you're um working um with your absolute own um a client is working with bright spot, there's there's no reason that like less has to be used. It's just um what we chose and we use a less um extractor for web back to pull out all the left to its into its own CSS file. Um but um whether any number of um patterns could be used to deal with styling, um we've also created this concept um of style packages um here that I'll get into it a little bit that allows us to have a different style sheets for the same set of renderers. Um It's kind of the, you know, CSS zen garden approach um for micro sites for certain clients, we found that a number of clients wanted um the ability to have uh slightly different rendered might like creating like a multi site um set up out of the same bundle where we might want to have a number of different sites um have um slightly different look and feel through CSS or even vastly different look and feel through CSS. Um but um use a the same set of renderers uh for that um sites that don't need this pattern and don't need multiple style packages, uh they can just use a single style package. Um But this um again with this out of out of the box, we provide two different CSS style packages um for Bright spot with one set of renderers, um and that gives you and this is why one reason we also went away from uh calling the front and bundle the theme is because really it's kind of it gives us sort of two different style themes for the same set of renderers, um and the word theme was confusing so we changed it to bundle um again we use less as our CSS pre processor. Um and for our CSS development patterns, um we used the B m block element modifier style syntax for our class and our element naming um versus doing something like object oriented CSS. Um Again, this is our out of the box, Bright spot, front and bundle. Um And by no means do you have to use Ben style syntax with bright spot? Like you can write your own CSS however you want to you can edit the handlebar renderers too, B o C S s if that's how um your particular site and your particular um and you wanted to be that way but for us, for a lot of the sites that that we developed for clients, we found that um using that band style syntax versus using object oriented CSS um for us CSS changes and bug fixes, they're less likely to just like create problems. Um It's your with them when you're looking at a style sheet, you know what you're working with and you know, which um particular um element and you know that you're working on um versus trying doing like object oriented CSS. Um It's sort of it's it's hard because it's your writing sort of one style sheet and then you're sort of using designations in html. Um and we felt that that is it's not quite as conducive to, allowing for multiple developers to work together um and Ben allows you to do that, so that's a little bit of the reasoning behind um this particular CSS development pattern. Um and that's what we use for our out of the out of the box bright spot themes and um the themes that we work with um for clients. Um So for us we use descriptive names um for modules and components um and use the band patterns to name their elements. Um So I'll show a few examples of what I mean by that really. Um And so here we have a page list which is um sort of a generic list of promos on the page. Um and you can see that, you know, our page list is our um top level block and it's got um some things such as uh called action or a next page link um or a header. Um That header has a description. Um The page list header also has a title um and that's the sort of pattern that we use for for naming certain things um for our modifier um rather than adding an additional naming to the to the class. Um We're using data attributes um as our modifiers. So for example, you'll see um data attributes use throughout our html and throughout our CSS um such as for example, um the uh the page list itself we'll have a modifier called data inverse colors, um and when that is set we write some styles um for for that particular modifier um in places where we need to so data attributes for our modifiers and block and element naming. Um for class names are patterns that we follow in or out of the box teams. Um We also use less to abstract uh certain styles um and allows us to use less extends and mixing depending on the use case, abstract styles and um that that pattern works pretty nicely. You have to be a little bit careful with less extends as and same thing with less mix ins uh to to not write very obtuse and very large CSS. Um But that's again that's nothing to do with bright spot itself and that's just a matter of writing less or sass or any any sort of CSS. Um So um you'll see for us like we create a page list abstract um that has some um particular, you know, display and background variables. It's got some treatment to its items array and each one of the items in that array. Um And then uh in a instance of a list we can use extend to drop those uh which is to basically, you know, provide those values into that particular instance of the page list. Um And then you also see another pattern where for things where that kind of extend uh didn't make sense. Um We just use some generic concept. So for example, uh in our for our side of the box, a page list header has some certain styles and it gets for code reuse it gets a page list designation and page list header and it has a certain amount of styles for its description and its and its title and instead of using extend in that case, so that every list extends that header. Um we just took our page list header and basically brought up a level to where it's its own um its own element um and it has its own set of styles and then each individual page list can override that header if it needs to. Um But we did that instead of using the extent concept as that creates a much more efficient CSS code base since we have a large number of list styles that each have the same header. Um So that kind of pattern was pretty efficient um And you'll see that reused all over the code base, whether it's for page lists or page promos or articles or any other such things. Um These types of patterns are there throughout. Um So next up let's talk a little bit about CSS um um and less variables. Um So CSS variables allow us to set um you know, values, whether that's in the CSS or um in line html. Um We feel that in our particular system and sort of any CMS really CSS as far as they're very powerful um as we've created a pattern to set CSS far through CMS editorial fields, um which allows customization of the styles of the site and customization of the CSS directly by editors. Um So we go ahead and we use um less variables um in places where actual variables are helpful um but overrides are not really necessary. So if we're using we're using a single variable throughout our code base, like something like media queries, um we use less variables for our media query designations, so we don't have to, you know, paste the same thing a million times. Um and then we can change the media query um with or whatever very quickly, but for some places, some places where um we might want to change that CSS um Editorially. Um CSS vars are a really great tool for that. And so what I'll show here is an example where we use CSS vars primarily are not primarily right primarily for topography. We used our use CSS bars. Um so you can see where we set some root um font styles. Um and uh we then allow editors to um we were able to create um and tutorial fields within the C. M. S, um where editors can choose um two different fonts, for example, for out of the box theme. Um and then these fonts um are set to these CSS variables um in a renderers um where these uh these pieces of data are used and they set the styling um But then our font one is the um uh are CSS bar that we use throughout our actual CSS um and this way, Sorry, clicked on the run. There we go. Um You found one is what we use throughout our uh are um throughout fault families, whether it's like the body or whether it's uh something like a byline or whatnot. And then we also use that way um an editor can set a different font inside the CMS um instead of relying on the default font and it actually instead of, you know, creating different classes or dealing with different things for that um with this particular pattern that the editor actually is setting a CSS far en route, which then um can get distributed um that CSS far can get distributed throughout our actual um CSS styling um or sorry, CSS files. Um So it's a really really nice efficient pattern um for um for things like that. Um we also use CSS bars um for sure throughout our code um for like actual CSS of our proper syntax to where um we can set a CSS var um let's say for something like a color. Um so we can set a link text, color um throughout our um and so then we can set every link to this particular link text. Um but then when we are down into some modules um we can just reset CSS variable um to whatever it needs to be rather than having to do cascading level, overrides. CSS bars allow that um to be used and that's a that's a again, it's nothing to do with break spot. Um but it's just a dev pattern that we chose to use in our bright spot theme but it's really just a it's a use of CSS variables. That's a, you know, that is why CSS variables were created. Um So this we definitely utilize that as much as we can um Instead of using less bars as CSS variables um since they're very widely supported now are much more powerful I feel than than less farce. Um So we use them as much as we can. Um So uh next up what we're gonna do is talk about the Jason in our front and bundle. So um Jason has um you'll see it all throughout the bundle and um it's used in two major portions and it's used his breeding because it's used to set the default um schema for the view um but it's also set as to it's also used to make the examples of the views um for that style guide application to use and it's used throughout our bundle for configuration. Um And whether that configuration is configuration of the style guide application itself or again, configuration inside the CMS to set certain fields um you'll see it all over the place. Um So now um yeah we'll go through um we'll go through some of that. So the Jason view examples are used in our front end bundle to simulate how the CMS is going to fill out the views. Um So uh to this allows us to create examples of content types um and entire pages locally as we're basically creating. So so the in the end when an editor is in the CMS and they're filling out um all the data fields in the CMS um and they go to publish that that um in the end it just creates a giant Jason blob of all of that data, so it's got all the keys and all the values um that are in there. Um and those are the keys and values that we as friends, developers specified um that we need from the CMS for the view. Um And so instead of getting that data from the CMS, we can uh manually create that Jason locally um to to simulate what the CMS is doing um which then once you add the style got application over the top um it then renders using our renders that um um using that Jason as it's as the data. So it simulates the CMS locally. So an example of that um is something like um the article page that we have in our um in the arctic, like in our bundle, um we have the style guide folder in our bundle which has all of the renderers for all the html um as well as all of these examples. So one example I'll show is our article page um and this is an example of all the data that is in the article page view to show an article on the site. Um and that we use the include um directive to include some generic values from page dot Jason. Um That that um every page content type shares. Um and then the article page has the all of these different values, sorry all of these different keys with values um that are in the article page view. Uh It has things such as dates. It's got headlines, sub headlines, it's got author information um it's got information such as bread crumbs and tags for that article. Um It's gotta lead uh it's got an article body which is obviously the content the prime of an article and it's got some some inside information for a side modules that are there. And these are all um when we create the article page view in that root style guide, we also we have all of these fields in there and then that is that contract that we've we've made with the back end uh team to say this is the data that we need as from developers to show the article on the site. So then this particular Jason file because it's since it's in the bundle, that's an example again of um if somebody were to fill out this data in the CMS, this is exactly what the Jason um it would look like coming out of the CMS but we just simulate that locally so that when this Jason is rendered using this article page dot HBs template. Um it's going to be, we can trust that um when we're running that local style guide application to do the rendering um it's the same exact thing that the web application is doing when it's rendering the actual article page using the um the same exact renderers. Um So again here we can fill, we use Jason to um we use this to fill out all of this example example data. And not only do we just have a regular article page um in our like out of the box theme, we've created a number of article pages with different options um that way when we run the local style guide application, um we can preview what, all of these different options which kind of similar to simulate an An editor making here seven different kinds of articles um in the CMS we make all those examples locally so that when we work on the article code base, we can see all of these stuff, all this stuff locally and working it immediately instead of having to go into the CMS um to create all these different pages. So here, for example, you'll see um on our regular article page, Jason example um you know, we've got the lead um and we go ahead and we created ourselves an example of an article page where the lead is set to null. Um We use that include directive so we don't have to repeat all of that. Jason over and over again, but we just include the article page which is the same exact render the same exact everything the same exact renderers directive with that template, it's got all that same data, but it's gotta know lead. And so now when we run the local style guide application, um we can see what an article would look like with and without a lead, so then we can write the html and the CSS necessary To to show those two examples of an article. Um and so that um pattern and that is used all over the place to create examples, not only of um single individual content types, like an article um but in our style guide we also can create entire other pages because again, since everything is the Jason blob, a homepage um is uh much in the same way like an article, um but it has its own uh view that we've created um for the back end um for the back end people to implement. So uh homepages again, and it takes a number of fields from uh like the the generic page um such as, you know, like meta values and and things like that. Um but it also has a lead where in this particular example for this homepage we set it to null, but then it also has some fields that contain modules and containers and uh and things and we again we simulate inside of this. Uh this bundled bundled view example, um what a home page would look like if an editor within the CMS and added certain field. So in this particular case we add an ad module in the above field that's available in the CMS in the main field. We add a two column container um with a couple of different page list modules as well as we go ahead and we add a couple of ads in there and some more modules. Um And then inside of that main we add some uh some quote lists which are lists of the quote content type which have multiple pull quotes, we add another add to simulate how that would look. Um And then we add some other page lists. So we basically um simulate what a homepage would look like. So that way again we can develop all of this um all of the html renderers and all the CSS um not only for this homepage but for each of individual modules and even use cases where certain modules might be on the homepage, we can write the CSS necessary to make those look however the design wants to make it look and we can do all of that work locally without needing to create this html and then build it and then separately and then deploy it out to an environment or deploy it out even to a local CMS instance. We don't need to do all that because we can get instant feedback by creating these Jason examples and and running this style guide application, we can get instant feedback on our development allowing for development to happen superfast. Um So next up we're gonna talk about how we use Jason for um configuration um So uh we have configuration files um and there are mechanisms to define um properties which impacts the way a bundle interact with both Bright Spot and the style guide application. Um All the configuration files that you'll see are the file name ends with dot config dot Jason. Um And the reason it's done that way is actually at runtime and at runtime of the style, the style guide application and at build time all these can figure out. Jason files are actually combined into one large configuration um Like very originally um in the uh in Bright spent a long time ago um we did have like a monolithic configuration file but we just found it was very difficult to to work with because it was just one file and just like they're like merge conflicts galore. So we split this up into a large number of config dot Jason files that are, how's throughout the code base um and they can be defined in the route of the style guide directory. Um And then subdirectories um when they're placed in subdirectories, it's the it's a best practice to keep your configuration file local to the components that are in the same directory. Um if you were to not do that and you name them something else, the Style guide application will try to warn you and I will just tell you like, hey you're creating some kind of confusing setup of configuration files. Um So you'll see that best practice followed throughout. So for example, if a, you know, a page list has a configuration file, it's placed next to the page list handlebar renderers and the page list view examples. So they're all in that same folder, so it's easy to see and they all kind of makes sense. Um And there are configuration files um for um all the different image size options that you can use. Um and I'll get into those in a minute. Um additional fields that the front end can add into the CMS. I'll definitely talk about that as well. Um Style variations of um of content types. Um And I have a whole slide on that because that is a very powerful tool and that's kind of the in a way like a primary front and development tool that we use to create different um style variations of content types um And as well as configuration options um for the Style guide application. Um And uh again the the global kind of configuration file which sort of includes all these lives in the root of the style guide And like I said in the beginning that at runtime and build all these things get kind of combined into one config um And that's what, not only the style guide application but that's what the web application uses. Um And that's what also this configuration is what you know the CMS uses um for certain content types. Um All right, so uh to get into image sizing for a bit um we we talked a little bit about how we use that resize helper um to use uh to actually pull image sizes from dims um and then set and get um but we have a configuration file which has all of the image size is defined that the resize helpers can use. Um So um we have this file in the root called image sizes that Jason and this file actually associates names of image sizes, which is what the resize helper uses to actual width and height values as well as source set descriptors, um and alternate formats of images um such as web p um uh with USB support. Um And there is uh there is some documentation on the on the on the bright spot dockside in terms of how with and height and maximum width and maximum height in this particular file can be used to not only to have dims crop you an image that's been uploaded in the CMS to either um Such as like for this particular case for a medium image. Um We're gonna have a actual image size aspect ratio. That is hard coded, We're gonna hard coded within height. Um but for some other image sizes like you see for this large to buy one image. Um That is not a fixed aspect ratio. Um It has a 840 pixel with um but it has a preview height you'll see as for 38. So what this means is that Um dems will return an 8:40 with by whatever height image has been uploaded into the CMS. So this could be a landscape image. This could be a portrait image. This could be a square image depending on the aspect ratio of the original um image that's been uploaded to CMS. This preview height definition is what allows that to be not fixed. But this preview height is what the style Guide application uses as an example of this particular image. So when if you were to create, let's say a promo module, um and then you were just use this to resize to this image height. When you're running the Style Guide application, it will return you, it Will happen to return you a landscape image because it will be 8:40 by 4 30. But if you put you know uh 1600 here in the preview height, it would turn you a very it would read the style guide application will return you a very portrait image. Um but with the CMS it will depend on the original aspect ratio of the image that was uploaded. Um There's also uh designations for um max. So this is like a great example here too. It's like there's another one which is like an extra large not fixed image which um We gave it a preview with 16 100 and height so we decided that we're going to fix the height of the image but not the width of the image. So you can uh provide these kinds of uh patterns to DMS and then you can also use a maximum width of maximum height. So it will resize to a ratio but only up to a specific size. Um And so anyways this image sizes file is what um specifies all these different image sizes which once specified in there. Um Then they can be used with that resize helper to the request these particular images and again you couple that with the set and get to create a nice reusable pattern where you can Have, you know, let's say one renderers to render an image um with a resize and get statement and then many different parent templates can can borrow that via the include renderers um to um to do image sizing and like I provide an example of that. Oh yeah that here. Um So um next up is a configuration um for front end fields um And this is a very powerful tool which lets us create additional fields into the C. M sorry not create but create and then add into the CMS additional fields that are added to the styles tab in the CMS. Um This pattern allows editors additional control um over certain styles of content types. Um So these our front end fields and these fields are only in the styles tab and as such, they only persist within this particular front end bundle and they actually are not part of that content types data. So it's important to only use these front end fields um for things like styling options and they're very useful for that. Um So for example it can allow an editor um to set a background color or it can provide image alignment options for a particular instance of an image. Um But what you do not want to use these front end fields for is actual data modeling. Um And the way that I kind of, I kind of say it is that front end developers should think about if they want, if there is a feed of data from this particular site um is the field that you're adding? Should it be in that feed or should it not? And if the answer is that it shouldn't then you should make it a front end field because for example, a data feed from the site wouldn't care at all and wouldn't need the information for a background color for a particular module. Um But if it's a piece of data, like maybe a link or something or a piece of text or a title or like a call to action. That data should be in the view and then that data will have to be modeled by the back end and provided either by a CMS or an A P I. And then it would make it into the feet. So again, it's very important to um make sure that these front end fields are used for for styling options or for display options of a particular front end bundle and because they are not part of that content types data. Um but I have a couple of, I've got some examples of that here. Um And um so if we define this fields dot config dot Jason file or we create this file and that has all of the different fields that we've created, um that can be used throughout different modules. So for example, we've created a field for a background color. Um and this allows um this uses the type color, which is that this stuff is also documented into in the bright spot documentation in terms of what fields um um And what kind of groupings and fields and are available and what kind of what types of fields are available to use here. Um And so uh for a background color, it's a type of color which in the CMS produces a color picker and allows editors to choose a background for a module. And then this background color field can then be used throughout different modules. Um in um throughout different modules, modules. Content types and style options of that content type. So you'll see um that here. Um we have a page promo module and we have different options of that page Prima module, A, B, C or D. Depending on on different looks and fields. But you'll see that page promo module a gets this background color, as does Primo module C. Um they both get this field. So when you, when an editor's goes in and chooses the style of page promo a when they create a page promo module, content type in the CMS, some additional fields will show up for them. Um In the CMS, we also again, something like image position is very useful for um for this kind of field as well as for example in verse colors. So you'll see in the fields um we've got inverse colors uh um Right here, where are you, little buddy? Um It's a bullying type of field which gives a checkbox in the CMS. Um and it allows the the editor to change the primary text color of a particular module to the primary inverse text color. So it basically allows them to to flip the colors. These two colors are actually set in the theme colors and they follow that pattern that we talked a little about a little while ago, where um editors get to set some theme color fields, which end up setting some CSS variables in the root, which then can be used inside of modules. Um And then this particular kind of um front end field, this type of particular field. Um and this particular module will flip the colors on this module um from regular to inverse. Um and then alignments um um image positioning, for example, we allow we have some front with some fields for uh image position, vertical, where we give them give the users and editors a drop down to say you want to put this module at the top or bottom of your module? I'm sorry, the image on the top or bottom of your module or depending on what the module looks like we've got, we've give them some image position, horizontal options, so they can move the module outside the image to the left and the right of the module. So you'll see that again here, like page promo a has a certain kind of look that we want them to give to have vertical control of the image positioning. But page promo module C happens to have the image next to the text, so we give them give editors the control to move the image left or right on the text. Um So this allows reuse of the page promo module C. Um because it can have the image on the left or the right via this additional editorial style choice. Um for and it's. So allows for great code reuse because the editors can can do all kinds of different stuff. They can put background colors that can inverse the text, they can move the images around and they can create very many looks using one particular module or content type style. Um uh So next up we're going to talk about these styles of content types. Um and this is a very powerful tool and I wanted to kind of talk about this like towards the end because I didn't really want to talk about in the beginning because I feel it was gonna be a lot of stuff that might have been confusing, whereas sort of at the end, I think it kind of ties a lot of things together. Um and it's a a style of content type. Um It allows us to define style variations of that content types, which then allows us to use different handlebar bar renderers and different um CSS and thus different CSS um for um single instances of a piece of content types, it's a very powerful concept um that lets us create many different looks of a content type and use the same data schema. Um So for example, um style variations Of three different content types. The page list, the page promo and page promo module. They're used to assemble a whole lot of pages like the home page and section pages and and big pages where um their primary content is a bunch of modules. Um So but also the style variations, they not only have to be used for these tiny little things, but they can be used for very, very big things. Uh So for example, uh you could have two different styles of an article page. Um You might could have um I don't know even what they would be called, but so um naming these things has always sort of been a problem. So in the in the DEV world we created, and you'll see throughout the code base um that we call these styles alphabetically. We have a, you know, style, A style B, style C, style D. And that is what they're called in our code and that is what they're called um in in our code base. Um and thusly without a display name designation, that's what they end up being called inside the CMS. Um but we do have the ability to use display name designations to call them whatever the editors want them. So, if editors and a particular client and a particular project decides that I don't want these called page list, A, B and C. I wanted to be called, you know, page list variation blah. Like we can use the display name designation to do that. But for some, it was it's very difficult to come up with those names and different people argue over that. So we just went with alpha alphabetical names, which um which are very easy to, to deal with for developers and again we can use discipline names um but nevertheless, a page list. Um a um let me go into and show that a if we look at the Front End Roots style guide and we look at a page list, content type. Um what we'll see is that a page, this is the view that's been defined for what a page list is. And a page list has a title, a description, An array of items, which can be one of many different modules, but really page promo an I. Frame piece of html or some ads but really like the primary use case for a page list is a page promo module. Um Also a list has um called Action Button with the um with the U. R. L. And some potentially some pagination at the bottom to to deal with this items array. Um and then a page promo um is uh content type that basically promotes a different page of the site. Um It has um a title, it has a description, it has a link to that piece of content. Um It also has some potential author information about that piece of content and and some media associated um with that content. So this is the view. And so in the published date as well. And then in the category of that content. So, right, this is the schema that we've looked at and we said this is a piece of um a piece of content that is used to promote something. A list is a list of those items and that's a very fundamental um data schema um for a module on the site. Um but then a page list um that piece of data can be represented with a very, very large number of looks and we call those styles that we call those front end styles. Um so out of the box, what in bright spot we have, I believe like 24 versions of these lists. Um and so we have 24 styles of these lists, so we can represent that data. 24 different visual ways. And then editor when they create a list of promos or, you know, list of Promotable inside the CMS, they go into the styles tab and then they can choose from 20 five different looks of these lists. And that way they can create very different, very robust pages with very many looks with the same data schema. So are a huge portion of our job as a front end developer is creating these versions and creating these style options, um whether it's for lists or individual page promo modules, because sometimes um you're not gonna have a list of things, You're just gonna have a big old promotable to a single object And for that we have um this content type called a page promo module, which is just a single stand alone um Promotable module that lives outside of a list and it just, most of the time, it's just across the whole page. Um So an editor's going, they're going to create a page, they're going to drop a bunch of lists and a bunch of promos on that. And um then for each one of those, they're gonna choose the style option. And much like we have 20 something options for lists. I think we have like five different options for what? A page promo module might look like. one of the style options has the media which is the image on the left or right. One of them has it at the top of the bottom one other option uses the back the media as a big old background image with overlaid text on top. And then so we create all of these as front end developers. We create all of these different style options that the designers have developed um and were reused the same data schema of a page promo or page promo module or a page list. But then we create all these different styling options. And again, as I was saying, that's not by no means are these styling options limited to just page promos and page lists. These style options exist for every single or can exist for every single content type. So if you go into the bundle. Um and you look at some other content types, um some of them might only have one render because they don't have, they only have one style that the designers for this particular um bundle have only designed um one version of that content type. But some others like for example have have a bunch more like I think maybe it quotes a good example where like we have we have to so they decided we have a quote list which is a list of quotes. Um and uh that can be that quote list can be placed on a homepage to call out some some quotes from people and The design team has created two versions of that. So you'll see quote list A and quote list B. Um for us, I think quote list A. Is like a grid and quote quote quote list B is a carousel of quotes. Um and then but we create the html, we create the styling for that and then we create this configuration file that says hey uh These are the two options. Dear editor you can have quote list A. And quote list B. And here are the the examples for what a quote list it looks like and an example of a quote list B looks like those are the examples that we created um in the front and the bundle style guide. Um so we kind of show exam show editors what they might look like. Um and then when the style guide application is run um it renders these Jason with these handlebar files and we can work with these uh lists um locally without having to go into the CMS. But when you do, editors have the choice of I am making a quote list. Do I want to make it look like this one or do I want to make it look like that one? And and it's a that that style option can be applied to basically any content type and can be used all over the place to create different iterations of of content types. So Um like one place for example where we don't use it in our particular out of the box bundle but that's why I was getting in the beginning is like article, we only have one article page because our editors have said every article on you know this, I'm sorry our designers have said that every article on our site looks the same, looks like an article but there's no reason that like you couldn't have like a really thin article and a really wide article or like a you know, article with some other stuff and whatever and you can create a really thin art, article, page thin and article page wide. And then when an editor creates an article page content type in the CMS, they can go into the style tab and then they can choose which style of article would I like. And again that pattern can be used for every content type and that's sort of our primary tool um for um going through and and creating all these different style variations and that's um, it's, it's almost primarily what we as front end developers is work with, that. We not only create the default versions of these content types, but we then also create every style variation of those content types that has been designed in order for editors to be able to build the site. Um So what, what I've got and so it's sort of to kind of sum all this up and um to piggyback on top of the um style variation stuff we just talked about. Um I wanted to have a small code example that I was going to show um of how to um create and make a new style of a page list content type. Um so you guys will have access to um the training repo which had, which is going to have this code sample as well as all the um code examples that I've been clicking on and showing. Um and that training repo has um the full, you know, the full latest roots style guide as well as the front and bundle. Um The style guide application can be run um on top of that as well, um so you can run everything locally and and play with that and see what's going on. Um But this particular code example is I think of um pretty standard use case that happens a lot and it's a, it's a very basic one, but it's a fundamental one of the designers and the product people saying, hey I want a new style of list module to be, you know, place, let's say on the homepage or something like that. Um So um there is a number of steps and tasks that we're going to go through um as a front end developer um to create this new list style um from a from the current training code base. Um And like I said, I've created a pr and a branch that has this list style and then I'm gonna go through each of the individual commits um that are necessary to do this work and kind of show that code um and also show it running uh show the style guide running locally and how it looks like um with and without that. Um So um step one is going to be um if you were to make a new style of the page list module, um you're going to create a Jason file for the example of that list style as well as the HBs renderers um uh that you need for that particular module. Um So uh that committee is going to be here. Um So what you'll see is that uh you in the front and bundle um We actually already have like 23 or 24 or whatever. 20 yeah 24 list styles. So we're gonna be making a brand new one called page list Why? Because we already have a page list X. And um we just have to get creative here and say that, you know, the design team has asked us to make a grid of a of a page promos. So so when an editor um goes into the CMS and this is what we're simulating here is that they're going to use a page list um content type. Um They're gonna use the style for page list. Y and they're gonna choose that in the CMS. Uh They're gonna put a title, they're gonna put a description in there and we've got some some data helpers that are built into our um our style guide which allow us to do things like words or paragraphs or these things um that we have documented on the bright spot documentation site. Um And that that, yes, so we're gonna drop some words into this description. Uh It's gonna get there's gonna be a call to action um as well that they're gonna be able to add into the CMS. Uh there's gonna be a target. Um And then uh there's going to be an array of items. Um and they're going to drop a bunch of promos to certain articles. Um And so what that data would look like is that It would be an array of eight page promos. Um because they're gonna choose they're gonna go to the CMS, they're gonna choose eight different articles. Uh They're gonna choose list Y as a style for that and then they're gonna hit publish and when they do that, this is the example of what page list. Why with the Jason for that particular instance of the page list would look like. Um So then what we're gonna do is we're gonna create the renderers for that page list as well. Um So we're gonna have a simple conditional that if they for example, published an empty list, we don't really want to render anything at all. So we're gonna make sure that there's a conditional around that. Um We're gonna use our band style CSS class naming. Um We're gonna add some modifiers using this include um syntax. Um And that is just if you can then you can kind of dive deeper into that as you're going through yourself in that example. But that's the um that's the little include helper that lets us deal with like, image alignment or background colors and such. Um And then we're going to include a standard page list header, like every other page list module um in this particular in this particular bundle. Um And then when the items are placed we're gonna say that we're gonna make a vamp style class items and items, item um array or html. Um And then um what we're gonna use is this uh this little syntax right here that says um that if you um if they do include a page promo module. Um If they do a page from a module, we're going to include page promo. See that happens to be a pretty large page promo. Um but that's the one that design wanted and we use this syntax here um in order to um allow because when we look at a page list, um promo code or page list, content type um in the items there a notice that you can put page promos, you can put little pieces of html, you can put ads. So this this kind of syntax allows the editors to say I want to page promos and then I'm gonna put an ad in the third spot and then a page promo in the fourth spot. So this type of syntax will say if you do if you are going through this array and you encounter a page promo, make sure to use this big page promo, c to render it otherwise. Just let the renderers delegation go to the child and let whatever has been placed in the render itself. So then like an AD will render itself because each content type has its own renderers by default. And then at the end of that we're going to include the page list footer. Um and then the page list footer is what deal this little include is what deals with the call to action. So it creates a consistent call to action button across all the different lists. Um So that's kind of step one here, in in making this module is we make the example of Jason and make the handlebar. Um The next step is uh that we update the configuration file um for um page lists. So to make sure that page list why becomes an option for editors. So we go into this page links config dot Jason. And then um we add page list. Y we show the we we show this example that we made um which will basically create a nice pretty picture for the editors to see what page list, what it looks like. Um This width and height designation um is actually the size of that little example little screenshot there in the CMS for the editors. Um And then we add some fields is we let the editors choose the background color and the when we allow them to inverse color. Um page lists Y um in when they're making an instance of this particular module. Um So once we do that, we basically gotta render, we've got an example and we also have created um in page list. Um We have added that as an option for editors to add it. So the next step is to add some styling to that particular module. Um So we're gonna add some CSS so we make a page list y dot less. Um We go ahead and we extend the page list abstract just because it's a standard list and we know that this abstract brings in um some light treatments to the um items to each item in a list. Um And then, you know, in a mobile does we do mobile first CSS so that you'll see here that we've got and items are right for each item, we just added a little bit of margin. Um And then page promo c has its own set of styles. Um It's got its own set of styles for its title, for its category for its description. Um But I just wanted to do a little extra here in this because, for example, the editors um and if we go into um paige uh sorry, let me go into the code here and show you what the um Oops, but the page promo um paige primo si has all of these styles that it basically comes with, because it's a page promo see. Um but its title is title three, which is a smaller title. And um what I wanted to show here is like maybe the editors have asked us to make Hay in this module. I wanted to show up uh like this page page um Promo C but I wanted a big old title. So then we do we can do an override this way that says inp ageless y when the page promo title shows up, I want that soccer to be titled too, which is a bigger title. Um So, I would do this kind of CSS, override their um And then in the medium. uh media Query, which is 768 and up we're gonna do a two column grid instead of showing them in line with a margin underneath. So then I write the CSS, I make sure to include the c I'm sorry, import the CSS into all the list styles. Um and then boom, I've got the CMS done, I'm sorry, CSS. Um and then so the last step here for making this particular module is to go into the style guide configuration. Um because the style guide configuration has this uh navigation configuration, which which lets us sort of display all of these different list styles in the Style guide app. Um And then also we've created, for example, for us for for this particular bundle, we've created this page that has every single list on it and just like fires all the lists on the page, which is a simple way for developers to like make some global changes. And then look at this one page with Eleventy lists on it in order to to do some quick regression testing. So we add it to the navigation. So it shows up and then we also added to um to this page with all page lists, example page that we created. Um and then we can run the Style guide application locally on top of all this code. Uh So once you do, once you run that style guide application, Um uh it shows up at a local host 80 80 is where the style guide application runs and you'll see this is the style guide app. Um And then on the left side here is this navigation that that configuration file that we mess with, and you'll see list why is now here because that's the list that we added. And then you'll see it's got a standard list header, it's got some generic words that have been created um via that Jason example and then there is eight promos in this particular list. Um and they have a there's also a call to action based on that piece of Jason and then we can do some testing and we can say, oh, like when you're in a smaller media query, you'll notice that it's in line when it's in a bigger query. It's um it's wide and here and this is the example of that list wide stand alone that has been created. And then there's also this page with all lists and that's the example page. Um That I also added this page, Y list Y two at the bottom and this is this example page that we've created that has like all of our lists in it. That allows us for like a nice quick regression test and you'll see this module here, list y at the bottom and then some a good example too of like this local style guide is uh you know, we've got this um this running and this is this is what allows us to do local development because this is using list y dot Jason to um to to show it here. And it's using list wise um C. S. S and it's using list wise um um HBs renderers. So um I can now go into my I. D. Here um and I can start messing with this stuff and if I'm gonna be developing this module locally so I can say that I'm gonna go into this page list why that I created and I want to make sure that this title um if the editor were the type of super duper long title In here, I want to make sure that it shows up so I can change that to 90 words. And when I refresh my um style guide app instantly it shows this is what this module looks like with 90 words in the title. So like, oh man, that looks great. So I just stressed us to that. So I can, you know, put it back or if it's a super long title and I'm like, you know what is this module gonna look like if I only have three promos or something, if The editor only adds three promos. And so that I can add that and then I can refresh this instantly. Uh and this is what that module would look like here and this is really cool from a local development perspective because it also, you know, works for your handlebars because here I can say um you know, I can do my changes and write my html and say, you know, I might want to delete my C. T. A. So um do instant development, instant refresh and I can check out all my html um immediately in immediately locally work with it live. Um and then the same thing goes for the C. S. S um where I am and I happen to be in style one style package. Um But page list y has some of the CSS that I wrote, and so this is that example where I overwrote the title of the page promo with title too. But if I were to um undo that um you'll see that it's a smaller title, a little bit smaller title by default. Um in this particular module or if I were to, you know, for example, make it a giant title. Um This particular module would have this giant title um and that's like those are CSS concepts that are reused throughout the CSS but this is a good way of working on them. But what's really cool is I'm running this locally. I'm seeing what list why it looks like, I can see it in context of an entire page as well. Um and I can do all of this development locally instantly and then I can be positive that when I push this out into the C. M. S. That, you know, this same renderers is going to be used to process the Jason. Uh and this same, this is the CSS that's going to be compiled and um I can have confidence that's going to happen. Um but even having said that though, the patterns that we like to take this front and developed as front of developers is that we create this pull request. Um uh so I made this list wide style and I've made this pull request that includes all of these changes. When this pull request is created, we've got ci that runs um and uh does a build of this and gives you an okay. And then this particular pull request can then be deployed into the QA environment. Um and then when that when that pr is deployed into that um QA environment, then we can actually test on a real QA server and make a real page, make a real example of this list and we can confirm this for ourselves before we move it on to Q A to just confirm that everything actually is working as planned. I as a front end developer. I'm 99.9% sure that it's all working because I did do this example, I made sure that I, you know, check this is how big everything looks but I still want to double check and triple check in the CMS that everything is working correctly on Q A. I can also make a nice example page for the Q 18. So then when I go back to the ticket and I'm like hey this list style is ready to go. I can even link them to a test page that I created for them to to make their jobs easier. Um but that's that, you know, again this is an example of creating a little style and this pattern uh goes to every kind of content types. So um you'll see in our in the style guide application here that there's lots of examples of content types. Whether the lists for their their page promos with modules different kinds of list types. Because we have lists for paige promos, we have lists for quotes like this, is that what I was talking about earlier? Well you'll see you know, one of these guys as a carousel where another quote list style can be created as a grid. It's the same exact data with two different looks. We've gotta we've gotta stat list. We've got lists of authors um whether those guys are single column lists or terrorist cells of authors, these kinds of pattern is for these kinds of patterns are repeated throughout in terms of content types and styles of content types to create a very diverse site. Um And then not only do you see this individual content types in this style guide, but we have created um for the for the out of the box theme. We've created a bunch of examples of different full content types. Full page content types, such like an article and this is what I was showing earlier where um you know, you've got an article page, it's got all of this, this data and it's also rendering using the article HBs, renderers. Um but then I also created myself an example for here's what an article looks like with no lead. So that way I can simulate what the editor is doing in the CMS with this particular article and I can make sure that all my CSS everything stress tested against my examples locally. I can do that development fast instead of having to do like builds and uploads for every little, you know, silly CSS changed that. I do. Um and then we try to maintain a well curated style guide that has great examples of every content type where it's got article that's got vlogs, it's got homepage, everything out of the box is here in the style guide. So you can see examples of each one of these pages, whether it's a section page or a tag page or search results page or even a search results page with no results. Like we want all of these examples in the style guide because we want um I will curated style guide so it's easy for a front end developer to make some changes and instantly regression and stress their stuff locally instead of having to find this stuff after the fact of like, oh boy, I broke article with an overlay lead accidentally when I was working on the article lied because I didn't even realize it was like here, you should look at both. If you're working with the article page, you should make sure to check all your examples so that you can um so you're positive that by the time it makes it out to the real world, it doesn't break anything. Um so anyways, that is um everything I have in terms of training um again, we kind of talked about every kind of an overview of every portion of the front and development, um kind of thing, starting at sort of what we do and what our stockings and responsibilities all the way through every single portion of the style guide um the the bundle and kind of light example of how we develop um if anybody has um any questions after this um um I think that um there's going to be like an email sent out with uh with um recording, like a screen recording of this as well as all of these slides as well as access to the training repo um and then for people that are more back end oriented that might have been sitting in or if you're curious in terms of the back end, Brennan is doing the right the back end training tomorrow, which then goes into um the CMS, java code behind everything, data modeling and then the view models, basically everything from um from that until that contract that's with us in the front of developers into the view. So you'll get all information about how data actually makes it into that view, um and then if you have any questions immediately shoot them into the chat or into that questions box and I can answer them right now. Um but otherwise, uh that concludes our friend and training. Cool. So I'm gonna kind of assume that there's no question since there's nothing to chat. So thanks to everybody for your time. And as I said earlier, listen, it's gonna be sending out an email with follow up with sharing this presentation, as well as the screen according um and the repo for the training. So thanks to everyone for your time.