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.
Everyone, we will get started here in a couple of minutes just giving a few more minutes for, for people getting logged in here, I think I'll just give everybody one more minute, Go ahead and start after that.
Alright, Liz I'm assuming that you can hear me and see everything, yep.
All good, awesome.
Well, hi everyone, my name is tom happy, I'm a friend and architect here at bright spot and today we're just gonna be going over some, you know, basic kind of cliff notes around front end development over a bright spot.
we've got a number of things that discuss, we're gonna be going kind of over our whole front, front end stack, like really what front and front end development here entails going over each of kind of the portions of that stock, talking about what this style guide thing that we have is talking about how we kind of bundle our code and then getting a little bit in slightly in depth into handlebars, which we use for template ng.
And then lastly just go through a quick code example, showing showing exactly kind of, you know, the inner workings of everything.
so to kind of start off with like what does front end here mean?
So we can not only write the front end of the site but also if you create editorial, you know, controls for editors to kind of change the front end around a bit.
so our front end stack you know, these are kind of our technologies we use Jason mostly for configuration files as well as setting up the views, which is, you know, the what kind of data we need on the front end, we use handlebars to deal with html template.
Ng we use less as a CSS pre processor will get into that a little bit as well.
web pack is our module bundler.
We use yarn to deal with our workflow and to to, you know for packages and then node we use node to run the style guide application.
It runs on node and does all the processing that way.
So now I like getting into each of the pieces.
We've got this what we refer to as the Root style guide.
you know, we kind of call this sort of the glue between the front and the back end.
but the Root style guide it originally lived in the project Root, which is why it's called the Root style Guide.
but now it's like we've moved everything into this front end folder, so like all the front end things left there.
so it's located in the front and style guide folder, and it specifies the views which are a collection of fields.
Each view requires a Jason file and then the handlebar file which is its renderers and it's the hook to be the renderers.
and then each view results that we create results in the java interface and then that is what the back end has to implement.
That's what we're going to get into tomorrow in the back end training, talking about how to do that.
But essentially, the route, the view is Jason, Jason schema and all of the fields that we as friend and developers need to display that particular piece of content on the site.
so the what we do is for example, create a view that says, hey we need, you know, the article title to show an article, so we will put the article title in the Jason.
Once we do that, the back end of, do the data modeling, they create the modules inside this CMS and they create view models that place that actually place that data into the view.
so the contract and sort of the glue between the front and the back end is that Jason view that we create.
That's the data that we as friend.
And developers need to show that and then the back end of snow that that's the data they need to provide us to show that piece of data on the, I'm sorry to show that view on the front end how the back end of get that data to us.
It's that's the business logic, that's what the view model is.
some of the time, like most of the time the data comes from the CMS because something like an article title could be put in through the CMS by an editor.
but it could come from kind of a back end api can be ingested.
It could come from whatever it could be hard coded in the model.
It that's the kind of stuff that you're going to get into to tomorrow.
But what's important for the front end of is that we're the ones that create that view that say, hey this is the data that we need to actually show that.
And then the root style guide again, that's the place where we create these Jason files that are the views for each of those content types.
so now we'll talk a little bit about the style guide application and by the way, if anybody has questions during this the go ahead and place them into the chat and then I can answer them sort of at the end or I can kind of chime in in the, in in the middle if they're super relevant like the to the slide we're on but go ahead and throw any questions that you have directly into that webinar questions panel.
So the style that got application, that's what I was talking about is the no Js app and that's an application that runs locally on on local host and it processes the example Jason view files that we create via our actual handlebar renderers.
and it essentially simulates what is happening in with the CMS data entry and rendering on the actual website.
So essentially it's, we can create example Jason files that are sort of an analog to an editor filling out that filling out data in the CMS and we're simulating that locally.
and it allows us to work locally and then see our work instantly and because it's using the exact same code as the life site, you've got trust that the same code is going to work correctly once deployed.
So again, this is our this is our way of being able to work without a front end developer having to run an instance of the CMS and then having to write a whole bunch of code and then compile that into a bundle, deploy that out into a CMS, just to see what they're doing, just like, you know, verify some CSS or something like that instead here, what we can do is work locally.
and the same thing with the handlebar files, so you can directly make some changes and instantly see them.
And we'll see an example of that at the end, When I go through the code example of me, like just like editing some stuff and see it working that way, You can kind of see how quickly we can develop locally.
So now talking about the front end bundle, the front end bundle is we originally called it the theme but the word theme is a little bit weird in the sense that like people just kind of what they think of when they think theme, so we just renamed it sort of to the bundle and that's really the whole front end of the site.
It's what we basically, all that we work with is front end developers because it has everything to show the front end of the site.
and so you know, we'll go through each of these and kind of talk a little bit more in depth about them, so handlebars for rendering html.
So bright spot uses handlebars as our temporary language.
we like that because it does have in its logic list.
And even though it is logic lists and and it's supposed to you know by the base and it's supposed to be period logic list.
We realize that by providing a set of helpers we can really make composition of templates quite a bit easier and a little bit more straightforward.
and then with those helpers we use comparison helpers, logical helpers and some math helpers and you also have the option to create your own.
and there's a link in the presentation to actually if you just google bright spot helpers.
It leads you this is the first result out in google and that's where we not have the collection of helpers that we have, I'll go over some of the most common ones that we use here and talk about them and but one of the things to to note again is this these helpers are meant to assist in the comp position of templates so you really shouldn't be using these things.
And you know, you still still still should be using handlebars as a lot as logical as possible and just use these these helpers and creating templates going through some arrays, checking against some math numbers and not doing things like dealing with strings or inserting data or or things like that because that's really what what should be done in the CMS and in the few models And then there's a couple of questions here that the by the way, I forgot to mention this at the beginning of this whole presentation.
Yes, the recording of this is going to be sent out and then as far as in the slide earlier we're talking about the theme versus bundle.
and then yeah, that theme we've got the it's the front and bundle is in the application and the directories as well, it's it's called the bundle now, instead of thinking the old like some some of the older bright spot versions, we had themes everywhere and now we're calling we do have it's called the front and bundle everywhere.
so some of the front and helpers like I said we've got some equal greater than less than just kind of very standard comparison helpers, they're not in handlebars by default, but they're great for moving through item arrays with some logic or some conditional renderings.
And when I get into the code example, I'll show an example of that.
but for example, if you want to, you know, maybe make the first item in a an array be different or something similar to that.
This these are great helpers but again, we shouldn't be using something like this for string comparison because that's where like stuff can get pretty nasty and then you're kind of building lodge like super big and logic into your templates.
We really want to use these more to help you move through item arrays.
Another really good one that we've sort of used all over the place, our setters and getters because we do a lot of delegated rendering where for example a list has a set of items that that renders each of those items.
Those Children items don't actually have scoped to the parent list or some settings or some things that the parent list might want to push down into its Children.
So now we've created some setters and getters that allow us to set and get variables or values.
and then that's really helpful in reuse of templates so that you can have a Children template that can get reused across a number of parent templates and the parent can just set some values throughout those.
We use this a lot in image sizing which I'll get into an example of that a little bit later.
We use an include helper and that really sort of works well with with the setters and getters from from four because it literally includes another template within a template and passes it the current data context.
So this really supports template reuse and this is sort of the main tool we have for template reuse because for example we can have a template that renders an image or a template that renders a link and as long as we pass it, the data that it needs, it can render that.
So that way we don't have to literally render a tags in every single place where we need a link.
We can just include literally the link template and pass it the data that that particular parent template is trying, it has to do with a link and then that way link is rendered.
So we do a lot of our template reuse using the include helper and then we've got this render helper, that is this contextual rendering concept and that allows us to render a specific style of the template as the default one.
So this one is great.
For example, if you have a whole bunch of different styles of an existing content type, so if you have a lot of different looks of a list, then the editor, when they start, when they create a list in the CMS, they can chew choose the style of rendering of that list, whether it's a grid or it's a list or whatever.
However many different styles we might create for that particular content type.
The contextual rendering concept allows us to basically specify a default style if the editor does not or allowing the editor to maybe not have to even make that choice, but it's just like hey on this particular section page we always want to render a list as a grid style and then the editor can go in and override it to be a carousel if they wanted to.
But by default it would render it a certain style, so we use that in selective places where it does make sense for that.
And then we've got a resize helper that we've created that deals with image sizing.
The resize helper is a directive to get a specifically resized image from dims which is our image sizing system that lives in the back end.
And then this can be used along with the set and get helpers to allow for code reuse and to do contextual image sizing so that you can have you know the template that is reused a whole bunch and a parent can just set some image size so let me get through and show actually this kind of in the code, I think it's a little bit helpful so you'll see that we've got this image tag that is a template that we have that uses the resize helper to resize an image to a particular size which we specify in a configuration file.
There's also a a fallback helper and a get helper and it's all used kind of together here that says it re sizes the image.
and it tries to use the image size getter if it's been set and if it hasn't it will resize you to a large 16 by nine, which happens to be our default image size that we have here in this particular bundle.
And then you can see where in page promo module a which is a style of page promo module.
we set the image size to be a certain value that you get extra large 16 by nine instead of the default regular 16 by nine.
And then we use the include helper to then include the page promo media which then that the file also includes the image.
And then that way we do a lot of template reuse by being able to use something like set being able to use include, which eventually comes all the way down to this, renders that actual image tag which actually happens to be inside of a picture tag as well.
And once we get all the way there get helper gets that image size that you originally set and specify as a custom image size for this particular module, whereas a different style of page from a module could use a big square image or something like that and then the rest of the code gets reused all the way down using these includes and eventually uses this resize helper to make sure to get the proper image size from from dims.
And those image sizes are specified in a configuration file which I'll show a little bit later and then that's where you tell dims, you know what the width, what the heights, what the etcetera is for this particular image name.
So getting back into the So sorry, so that's about what we all that I have in terms of going through the individual helpers.
Like I said if you either google bright spot helpers or go into the link that's at the top of this section of the presentation that's got the rest of the helpers and how to use them with documentation and whatnot.
That is E.
That's a mixture of classes and custom elements.
We use Babel to transpire it into browsers that we're actually gonna support.
We use the browser list to to deal with that depending on what browser support you need.
That's you know, you could include as you could compile a certain file that maybe only a proportion of the pages, proportion of the site's gonna use.
So that way we're using handlebars to deal with all of the rendering you're getting static html.
The that is then heavily cached, it's got all the S.
Benefits and everything else.
So for example if we had something like a very complicated leaderboard application on an otherwise content, you know driven site you could make that leaderboard application a react app that uses graph QL to pull its data does all of its rendering and it's an actual big old application and that thing can be in stance created via a custom element and that whole application can come that way to where the page is still in the CMS but then the rendering of that data might come from some A P I and use react.
So we definitely support that and we definitely have done that and use that but again, for sort of the generic, you know, page that just has content, we feel that that's better to use html template ng.
This is a very straightforward little custom element.
that is a carousel, that is a custom element.
This is on every page because there might be a carousel but whenever it is and whenever it does get detected in the html, then we do a dynamic import of Clickety, which is the heavy code that is driving the carousel.
So we really only have, you know, some options or something like that that that that live here.
so that you know, because because you need it but you don't want it compiled into every single page and come with you for every single page.
So having said that now let's talk about some of the styling and how we do C.
so we use less as our CSS pre processor.
There is no really like this isn't like baked in and like we have to use less, we just chose it as our default bundle and you know, bright spot go and what sort of comes out of the box with the bundle that we create is using less.
And there's no reason that if you know for example you were doing a front end for a new bundle from scratch or something like that, you could buy by all means use sass the only really thing that's making this be less is the fact that in our web pack configuration we're using a less processor and we write our CSS with less less syntax, it would be pretty straightforward to convert that to SAs or use, you know, the vanilla CSS or however you wanted to write your CSS.
But having said that we use bem style syntax for class element and naming versus moving our CSS into like a fully object oriented CSS kind of boot style directive based html.
We feel that this sort of bend style and I use the words them style because it's not purely bam like by definition it's just kind of that style and it allows for sort of CSS changes, bug fixes and we feel that they're less likely to create regression issues because the bench style syntax when you're writing your code, you're actually making changes to elements or modifiers or even blocks that and you kind of know what you're doing, you know what you're changing and you're not really affecting huge other portions of the website where it's kind of an object or a CSS architecture really puts the control of the CSS into this like one major area and if you make changes there, you might be affecting lots of other places that have used your object oriented CSS classes and you might, you know, make some really wide changes when you meant to just fix a small bug on some particular module.
And also this allows, you know, we feel this allows multiple developers to work together more easily or for somebody to just like jump in and some somebody to do a little bug fix on a particular element of a particular page, that Again, without really messing up something else, without having like full knowledge of how the object oriented CSS framework works for that particular site.
So that's why we've gone with sort of again, the bench style class names.
So having said that, we use descriptive names for modules, components and then we use kind of that bend methodology to name their elements.
and then we use less abstract certain styles.
It allows us to use less extends or mix ins depending on the use case.
Same sort of concepts as with SAS.
But to show a couple, I mean show a couple of code examples on this.
So there so you'll see for for example when we create a page list you know, there are gonna be some classes that are that belong to that page list such as for example, a page list header can be You can use the page list class and it can have all of its styles combined and I'm sorry, all of its styles in page list and then pull them from their But a page list.
That is a page list standard a which is a style or a look of the page list module.
It can then Right, it's CSS in this in a way that it can edit the way the page list items look.
Or you can use the less patterns for example that if you want to use less extends, we create these title elements in our less and then they can be extended onto particular instances of episode.
Promo title has a number of sizes.
And this particular list wants to use this particular title instead of the default.
That's created on page promo and this sort of pattern gives us some pretty fine grained control over what you're doing in terms of styling, in the sense that we've got these blocks and these like, elemental codes, such as like a page list and the page list header and how page list items might be displayed on this level, but then you can override those kinds of styles on individual list styles or individual promo styles, which give you very fine grained control, but we feel that going about this method not allows us to sort of re use html templates all over the place because you're not putting those directives into html classes, you're putting these directives into the CSS.
and then it's easier for somebody to sort of jump into this CSS file and say and see what's happening.
The fact that, you know, page the standard a has, you know, this kind of font on page promo, trying to do that versus having to write that in the html promotes not only reuse, but then again, a developer can come in and be like, oh, I just need to change the font on this promo title for this list.
I know kind of where that is that's in the CSS instead of having to hunt that down somewhere where you might not know what's happening with that.
So, let's talk a little bit about there it is.
Let's talk a little bit about CSS variables and less variables now.
So we do use CSS bars through throughout a lot of our CSS whether that's in line, in the actual CSS or in line html And we do that to allow to create a pattern where editors can set CSS variables through CMS.
Editorial fields, like I said in the beginning, the front end team can create can create editorial fields in the CMS which we can then use we've we've done that with a number of with fields that allow editors to customize the CSS of the site using CSS variables and then we do use less variables for places where just using a reusable variable is helpful.
but those editorial overrides are not really necessary.
but I think the majority of our variables can be like I said, we can say that there are CSS virus and the show a few of these kind of show this pattern as well.
so we have you'll see here that there is a large number here of CSS variables that we set based on fields that we've created this front end developers and then put into the CMS.
So just to go with the first one, there is a primary color that a editor can choose when they when they set the theme on a particular put the bundle on a particular site, then they can go through and and customize a number of fields and they can set with the primary color is and then we set a CSS variable with that.
And then in our last file we go ahead and we set that color from the theme that they might have over it and create a little fallback for ourselves, let's say like if the editor doesn't it's gonna be red, that's our sort of default color but if the editor does set that it will set this color primary variable to that.
And then throughout our CSS we can then use these variables or override them again or do whatever we need to.
So for example, another one also is like you can set the color, the background of the header of the site and again that is here The editors have this header background color field where they have a color picker pops up and then if they don't choose the color it'll default to a white background for the header.
And then the page header code is what actually uses that CSS variable here and then that allows us to again have editors control over the background of the page header but create some fall backs for some colors if they don't do that.
And we use that pattern a lot for whether it's colors you can see there's colors, topography etcetera, anyplace where we want to provide that editor control over the CSS value.
and then here you can also see a pattern where we we are using CSS variables to reset our header height.
So while this is not a value that is being edited by editors this pattern works out really nicely for dealing with that like a header height where we just set it once in our header bar here.
and then we can we just change that variable around here with some media queries.
We use that pattern also quite a bit to deal with CSS bars.
Sometimes we do less variables for some things like for z indexing for example, something that might not be changed through media queries or otherwise.
So we've got a mix of CSS and less far as depending on the contextual sort of use case for that.
So now that we've got through styling we'll talk a little bit about Jason and how we use Jason for configuration files and to create this view examples that I was talking about in the beginning.
So to start off with I think the major use of Jason is creating these views and then also creating view examples.
So when you create the article page view and put that in that route style guide that tells the back end here are the fields that I need to render an article but then to use in the style guide application for ourselves, we create these Jason view examples that are used that are simulating how the CMS is actually going to fill out those views and that allows us to create examples of these content types or not even like in a content type or an entire page locally and view that in our style guide application, so I'll show you a couple examples here of that so for example, we've got a page view which has a number of fields that a page has, so we put that in our bundle style guide and then that is what fills out the view for what a page has that has all the values like it's got a logo, it's got foot or logo, it's got navigation, it's got etcetera.
We put examples of all of that here and then an article page is inherits off of the page, Jason, so it pulls a lot of those values from that but then it has fields and we're simulating what an editor is doing when they create an article page in the CMS where they, they're gonna drop in.
Some authors, they're gonna drop in some tags, they're gonna put a figure or an image into the lead of the article and then they're going to create an article body.
So here we create a bunch of Jason that simulates what an article would look like.
And then you can see there's a template here that this article pages rendered via article page dot handlebar file.
and then this allows us to process this article, Jason example that we created with this handlebar file and when we run the style guide application, it processes this Jason with this handlebar file, just as if you publish this bundle out to the site.
the back end is what's going to create this Jason out of the actual CMS editorial fields that have been created and they're gonna fulfill this view fulfill that view with all of this data and but it's going to process using this exact same handlebar file.
So whether you're viewing this in the local style guide or on the full site, it's being processed by the literal exact same handlebar files.
So when you simulate it locally, you're, you're, you've got pretty good confidence that when you get this out into the real real world, it's gonna show up the same exact way.
And so this is an example of an entire page, but much in the same way if we have just a small little a little module, if you will the page list module.
and then here again, here's some particular, here's some examples where we create a Jason file for this particular module, we give it a template.
We give it a style variation template also to simulate an editor picking a certain style of this particular module in the CMS and then we give it some data.
and then so then where we can display this module and and look at it in the style guide.
So we also use Jason to deal with all of our configuration files.
there the mechanism that we use to define how the bundle interact with bright spot, but we also use configuration file to configure that style guide application.
So for bright spot, actually, whether it's nostalgia application or bright spot itself, the configuration files are image size options where we might specify all the individual image sizes.
they specify all those additional fields that the front end can add into the CMS such as when I was talking about those color color pickers or things like that, that we use these.
Config files to specify those fields we use also.
We this is how we provide style variations of content types.
So for example, a page list content type is just a list of promotional modules.
So that is how that's kind of like a bread and butter content type.
Where it's just a list of, let's say, you know, list A promo module is a picture of a title and a description and a link and a list is a list of those items.
That's kind of like a standard module that's used all over the home page.
And the homepage is just a repeat of those modules, but then they have different style variations because one's a grid ones, a carousel ones.
It's by itself on the page.
So this is where we we create the configuration to show all these different style variations out to the editor.
And then we use configuration files also specify options for the style guide applications such as like the navigation that shows up in the style guide app.
All these config files get pulled in together at runtime and build and combined into this one large configuration.
But we kind of litter them throughout the the folder structure and the code base In subdirectories we do that in order to just make it easier to read.
So that way, if you're dealing with the page list module, you can put that in the page list folder.
If you're dealing with an R article module, you can put the configuration for that module in the article article page folder rather than just kind of having them all together and having this giant config file that will end up having a bunch of merge conflicts if you have a bunch of developers working on it, and then to go through a little bit and and dive into each one of those options.
So we use it.
Again, Jason can fix for image sizing that is in the root of the theme and then that's the directive to dims to give you a particular actual image that is requested via the resize helper that we talked about earlier.
So here you can see a link to the image sizes configuration file where we define some some small some medium some large images and we put you know we we put the aspect ratio in the name just so it's easier to see.
and then this is where you define the width and the height of the particular image in pixels.
There's also you can choose variables and not fixed images so for example, you can say something like this where the it's a 14 40 wide image but it's not a fixed aspect ratio so it will return of 14 40 wide image with whatever however many pixels.
The original source image was uploaded into the CM into the CMS.
So if you specify a portrait I'm sorry if you request and this crop name of a portrait image, it will return you a super duper tall image because it's going to be 14 40 wide but if you have a super landscape image, it's going to be super short.
If that was the original source that was uploaded into CMS.
This is where we can also provide some source set descriptors to deal with picture tags and where we can specify alternative formats for images such as web P.
So if we want to get make that have dims return your web p version also of this particular image.
This is where you can make this a designation and then we use that in the picture tag to create responsive and performant images.
So now we're talking about the front end field configuration we can specify additional fields that are added into the CMS for editors kind of talked about in the beginning and that all those allow editors control over styles of content types or particular you know, fields that like a color picker or something like that?
These fields one important thing about these fields is that they persist only for this front end bundle.
They're actually not part of that content types data and that's one of the most important thing about these front end fields is that you're not actually changing the data for that particular content type, You're just changing Are you that you're as a friend of developers allowing the editors to change or to add some additional data to that content type for this particular bundle.
So if you have two different sites with two different themes, they could take the same piece of data but display something visually very different depending on what has been chosen for, created for styles in that particular theme or bundle.
This is a very useful tool for adding additional styling options to modules such as background colors, image alignment etcetera etcetera but it shouldn't be used to supplement the content types data because if you do that, that data doesn't actually ever exist as part of that content types data.
It just exists for this particular display of the front end of this, of this bundle.
So, for example, if you had a feed that you were, you know, if you had an article and you added a subtitle of an article using this field that sub entitled to, that article wouldn't actually exist in the data and it wouldn't make it out to any feeds that have to do with that article because it would only be for that front end bundle, which is again why we sort of want to use these fields for things that have to do with display options because that's tied to this bundle or or theme depending on where you want to use.
So an example of that is that we we specify these fields and these fields, configuration file, we specify them here because a lot of these fields can be reused across different modules, so we don't want to specify them in each of the individual module, configuration files, but an example of this would be that, you know, page promo module is a single module.
That is a page promo content type that has, you know, an image of text, a link, and a description or something like that and in a category of byline.
And so certain styles of this might have some text alignment or an editor might be able to change the image aspect ratio of the image that goes in that Prima module.
or they might align, you know, put the image position that's horizontal is like this particular module style happens to have the image aligned next to the task sorry, next to the text horizontally.
So an editor might want to position the image the left or to the right.
So that's why we have this and this is where we say that when an editor select this style in the CMS, then they get all these additional fields that are shown to them for that particular style where they can choose to, you know, hide the category and that promo module.
If you want to make the display easier, you can show the byline on that which is kind of hidden by default and are in this particular bundle.
You can choose the aspect ratio, the position of that image.
That how wide that images, whether it's like 60 you know, 60 40 or 55 50 or they can change the background color of that entire module or they can inverse the text color.
So if they choose a black background, they can do in verse two colors to be white.
or we've got some options for like animations to where you know, as you scroll down the module might animate in or something like that.
And then the editors can make all of these choices editorially for this particular style or instance of a module.
and and we create these fields here in this configuration file, so we can create some bullying fields.
we can create, we can grab records, so we can choose like a background video of a particular style, we can choose images to do a background, image or image, color.
the color type will choose a color picker.
So as front end developers, we can influence what the editorial interfaces and we can give control of the editors for these visual to add these actual visual elements or control these the visual representation of these of these modules.
So that's basically, you know what I have for the general overview, this was definitely meant to be kind of like a cliff notes around how the front end is is done here.
If you guys have again, any sort of questions about over actually, you know what I just called down and I see a couple of questions, so I'm gonna go through and look at these questions and kind of answer them right now and after I do that, we'll go through a quick code example that will show making a new style of the list content type and on how some of these concepts are used.
So Danny mentioned that the link for the helpers is actually broken.
So I said if you google bright spot helpers the first that comes up and I'll fix that link in this presentation before the presentation goes out to you guys.
So the includes are different from handlebar.
There's a question about how includes are different from using just handlebar partials.
these handlebar partials have to be sort of defined as partials and before they can be used where this the include helpers allows us to basically essentially literally point to a different file to be included in that particular context.
So instead of it being kind of a helper that has to be created has to be defined etcetera etcetera.
You're just creating you know, you're creating a file and then you're literally including that file, so it's a little bit sort of easier us And then also so the big thing is it it allows you to include helper allows you to pass data and change data that you pass to that particular to that particular file.
So we felt like that pattern kind of allows for better code reuse.
So we kind of use we use that include helper instead of handlebar partials sort of by default.
Okay, and there's another question about update, Like updating?
No Js or detaching no Js for using different tools, like so the like node isn't really built like there's no like attachment or anything or is it like it's not built into here.
The style, that style guide application just happens to be built using node so that when you're running the Style guide app, and you want to preview, you want to work locally and you want to see all of these Jason examples and have your handlebar process.
you're not like we're not actually using node to display the front end of the site.
We're just using node to run that application which allows you to sort of simulate the CMS locally for faster local development.
So that answers this guy's your guys questions if it doesn't let me know and I'll try and enter in a different way.
so now we'll go into the code example that I have.
so the example that I have is making a new list style so when you first run run the style guide you'll notice that there is a large number of list styles that we have.
And a a list a page list is a content type that has pull up the the repo here.
So a page list is a content type That has a look in the root style guide and show you a page list.
A page list Is a content type that we've defined this view here where there's a title, a description a set of items as well as like a C.
Button that can be displayed underneath it.
And then items are either page promo or you can have like some little html module so you can insert some weird stuff.
Or it can be like an ad that's inserted between the items editorially.
But for the for the kind of main use case a list as a a list of items which are promos.
So like I said, that's kind of the bread and butter of something like a homepage.
And so we as friend and developers and our default bundle have created a large number of styles of the page list and we've named them here sort of in these little categories just so they're sort of easier for editors to to see and to understand what they're picking but we've got some page lists that are carry cells.
We've got some that are standard that we called standard, we've got some page lists that really only belong visually and like a right rail or or a rail of the site.
and you can in the style guide, we create a navigation that that displays all of these on the left.
So when you run the style guide application, you can see all of these different styles.
So this is a all of these different visual representations are the list content type.
but they all look differently.
Like, for example, pages Standard A.
Has this like larger image here, you've got four other promos and some of the grid on the bottom B is a stand very standard grid where editors can specify whether they want maybe two column grid for column grid by default.
It's a three column grid and, you know, so on and so forth.
So that we create like, you know, list D.
Is kind of standard single column kind of thing.
And we created a large number of these things.
So a lot of like the asks of front of development teams are to either create more of these or create different styles, that's what we're gonna do, is we're gonna create a new style of a standard of a page list module.
So to kind of start with that, you know, you you're gonna be provided you know, a design because this is, hey, I need you to provide this new look and here, maybe it's like I'll just we'll create a new style and I'll just give it kind of a generic look just because I don't quite have a design.
But what we're gonna do to to kind of start this as as developer is that you're gonna we're gonna create another style.
We've got lists, page list, standard, A through L.
So we'll create a new style, will name it.
M we use this naming scheme because coming up with names for all of these list styles is actually really difficult because everybody has a different kind of opinion on how they want to name it.
So we just decided to go with sort of the alphabet naming scheme in at least a default bundle.
And then in the configuration file you can actually choose a display name.
So if a particular project for client or editor or whoever wants to is using this bundle or you're creating a new version of this bundle or creating a these are creating that.
You can give more descriptive display names.
But since everybody has an opinion, we just chose not to have our own here.
But just to make these alphabet names.
So we'll be creating a page list standard M which which will just have a different grid look from all the other ones.
So to do that.
we will create the handlebar file and the Jason example of this and you can see that here where we've created a handlebar file to go with paige with standard M we've given it a class name, which is that black standard?
Standard M which is what it is.
We use this include pattern too to include the list header which actually includes the title and description.
We'd use that to kind of give it this sort of pattern to create a standardized list header across all the different list styles.
And then what we'll do is create a couple dibs to house all of the items that that page list is gonna have.
And then you'll see here we're actually using the a helper that says if for the first item in the array, what we're gonna want to do is set a larger image size.
And then use that include helper to include the page promo module.
That's it's basically child.
We're going to delegate the rendering for those Children over to this page promo.
But again before that we're gonna set an image size to be a large 16 by nine image because we're gonna have a slightly different grid where the first image is bigger than all the other ones.
So this kind of pattern allows us to create to reuse this page promo renderers for the child but again to use something like a setter on the first item to give it a larger image size.
So this is why we do that include pattern while we do this.
So that that page promo code is included once rather than having to copy and paste that code all into these parent templates.
And then what we do is we create ourselves a very straightforward example of this page list standard.
M so if an editor were to go into the CMS and they were to create a new page list, a new version of the page list and select the page list.
M template that we that style, this is what the Jason would look like, that.
It is a page list template.
But the style the template which is the style that the editors chose is page list standard.
That's the render that we created up here.
and then you know, we give it a title just so it's we want that notice we're skipping the title description which is no big deal.
We can add that later if we want to see what that looks like in the local style guide.
We give it a C.
And then in that list in that items array we simulate the editor adding nine page promos into that.
So they might link to nine different articles.
So we're kind of simulating that here.
And so this is our first step in in creating this list style, the next step is we're going to edit the configuration file so we have a page list configuration file here and then we're and if I just pull this show the whole file here, there are, this is where we specify all the different versions of that particular list.
So we have all the different versions of this G H I J K L.
We've now added list em at the bottom of that list because that's the newest list style that that we've added.
we know we're gonna add a couple of very basic fields to that where you can, an editor could specify the background color or of that, or inverse the colors of that particular module.
And then you'll notice in this configure Father some width and height things.
So what are billed does whenever our build gets built and the bundle gets built.
Now we've got an application that goes and pulls up all of these different examples and actually takes a screenshot of that example on in a browser and then puts the screenshots in the CMS so that when the editor sees this list of styles of this page list style, they don't just see like a through M or whatever.
They're actually seeing the screenshots of what each one of these modules look like.
So they have a better visual picker, this width and height actually just specifies the width and height essentially aspect ratio of what that screenshot looks like.
So if we were have some module that's like super tall but not very wide.
We could, you know, make the height taller in the with less or something like that to show the screen shot a little bit better.
Which is but all of these are kind of standard list styles that are kind of gritty or like a grid or a list or whatever, which is why you see the same width and height for all of these screenshots sizes in the CMS.
So anyway, so this adding this into the page list Config gives the editors this new list style that we've created as a choice with the screenshot of this example file that we've created as the screenshot, as a little visual picker for them of what that style is gonna look like.
So the next step now we've got the renderers, we've got the configuration policy that shows up in the CMS.
So now let's write some styles for it.
and then you can so we have this pattern where we just we have an all dot less where we include all the import the styles for that individual version of it.
And then you can see here.
I just wrote some very very basic CSS where we do a 20 pixel gap on a grid.
We add a little border to the bottom and some padding just to make this visually look a little okay.
And then on some since we do all of our kind of styling mobile first we in the medium breakpoint which we used less variables to kind of define our breakpoint sizes all.
so that we're all using the same exact breakpoints for everything.
So in the medium breakpoint we're gonna go to a two column grid.
And like I said I think the first item is gonna span two it's gonna be bigger than the rest.
So that's why I wrote some CSS here to basically say hey the first item in the list it's gonna be across both grids and you know the rest of the items will span one.
And then the same kind of and then now that I kind of see the CSS like sorry we could have just skipped these lines because it's since it's well first we could just only override the stuff that we need.
So well we just go into a four column grid here and then the first item is gonna span all four columns here.
So we've got some CSS written we've got all the configuration files and then our last step here is going to be to add this page list.
Standard M into our style guide navigation.
So so it shows up on the left side of the style guide app and then we've got this like one page that that we've created that has every single standard list so you can see them all together just to make sure everything kind of looks good together on a page.
Once we're done with these four steps we can run the style style guide application and I've already got that running here.
So now I can go to my local host and now I see the Style Guide application running.
So now I've got all my standard lists here so I can view them in context of this novel or I can pop them open and view them in context of an entire page so I can more QA them and check them out and check to see all of that my CSS is working.
But now when we get to the bottom here we see the new standard list em that I added and now you'll see the CSS like everything working where it's got the standard header and then it's got a number of page promos on the mobile view ports, they're all together with 20 pixel gap and a porter, whereas when you get to the larger breakpoint that you'll see the two column grid and you'll see the four column grid.
So this is kind of that that working and kind of now to show like how this whole like working locally here.
So if we want to add some more C.
So for example here we look at this and we're like well this is a larger promo and it's got a big title and then the rest of these like kind of small and the title looks a little bit big so maybe we want to make that title a little bit smaller so we can write some basic CSS here and kind of add that and we can say that if you're not the first item On the page promo instead of having the default promo title which happens to be out size, I want to use promo title six which is an element that we've created in our topography file.
So in the global topography last we create a number of page sort of topography styles that we can then extend throughout our code.
So we created a number of promo titles here where we have one through six and they kind of cascade down in terms of size.
So one is the biggest.
Six is the smallest.
So here what we're gonna say is I want to use some smaller font size for every promo, that's not the first promo.
So I wrote write some CSS save it and then you'll see in the bottom right corner that re compiled my less.
And so now I'm ready to see this new less and now you see my smaller promo promo title font size here locally and it's instant.
So I can right all of my CSS here and I can change everything locally, hit save and see the stuff instantly in my style guide application.
So that way I don't have to write this code, pull it up in the C.
And and see how it works because I'm checking out locally.
So if I look at the page list standard m here, I've got the html here.
and I if I make changes here So if I, you know for example like undo all of this code and just make a list of items and then go into here and I undo like all of this this code for the first item.
Now I can make a very straightforward grid, I've got all of that and then instantly I can review my code and now I've got a little hanger because I simulated that an editor adds nine things.
So now as an editor I'm gonna add eight things instead of nine and then instantly go in here and refresh and see and I was like oh I can simulate for example that an editor did not include a C.
And I can see what that's gonna look like and I can check all that code out instantly and I can see the results of that.
and this is exactly what the CMS is, definitely.
See actually the first ones got still the bigger font size.
So I'm like, oh man, I've got a bug in my code, so now I can go in my CSS and say, wow, now that I have a full normal grid, I shouldn't do that anymore, I can compile that, I can refresh that, I can verify.
Oh yeah, everything's looking great here.
Or I might want to take out and say, not first child, so that every promo now get some smaller text because I've got a four column grid and it's like I see all of my changes instantly.
and then this is sort of, this is the main tool and all the main patterns that Oh yeah.
And then to show you this, like I said, we created this also this page with all the standards lists and your seeing all of these lists, they're just shown in this view ports and they're not really in context.
but since we can simulate full page content tiles.
you'll see here in this folder, we created this page with standard lists and this is actually an entire page that includes a page lead and then we simulated in the main of that page and editor adding each one of the styles of each of these lists together into one page and it's a, it's a page so we can view that whole entire page.
So when we pull this up here, it shows this in this little window with this navigation, just for sort of some basic coding, but you can also take these and open these pages up and in a tab and then this actually shows you this and dire page, how it's gonna look like.
And when you look at the code for this page, it is the page as it would exist on the full life site except you're viewing it all locally.
So this is, this is simulating and a standard page content type with a page lead that an editor has added with a whole bunch of page lists where they selected a list style for each individual page list.
So you can look this over locally, this is where you can say, hey, how are these lists working together?
How are these mod working together in the main or is there enough spacing between them that I write all that code properly?
And like at the bottom here, you'll see my standard list em that I've already, like, you know, made it changed up the CSS, It already looks good, I can check all of this locally and now I've got confidence that when I take this bundle and I it gets deployed out in this thurber, that standard list, m is going to work the same exact way here and on the web as well and this is not to say that like, you know, we as friend of developers, we can just like, you know, spray and pray in the sense of just like find this code, checking it locally and just like shooting it out to QA and be like, hey, we're done.
It works local.
Like we still definitely have QA process for developers where you know, we'll create a pull request with this code and that's what like in the training repo you'll see that there is a pr where it is, you know, this pr has been created and like on a normal project we would create this pull request, we can then have our, you know, senior developers comment to talk about the code and then we can deploy these pull requests out to our QA servers so you can deploy that code to a QA server, you can check to actually like double check to make sure it's working and really all you're doing then though is making sure that the CMS editorial interface is working.
That this feels like things are actually getting done correctly in terms of, you know that it's in there is an option for you, the screenshot like all that worked.
the editor can go in and select it, you kind of you want to view that you want to just double check that all of your code is working.
but what you can do purely locally is like I've got 1000% confidence in my, in the CSS here, so that I do know that if like four or eight modules are put in, this is this is what it's going to look like.
And so if I, as a developer am making some CSS updates, I'm, I, a lot of times, I don't double check that on QA because it's just CSS and I'm not actually editing editorial interface with the code that I wrote, which I am doing here, but if I was just changing the CSS, I probably would just go ahead and shoot that directly.
The QA because I have verified that my CSS change is working in this particular instance.
So if I wanted to make this, if I got a request to make the byline date bolt or something like that, I would just write that CSS right here and I would change the I believe it's called just by line if I just do that double check that my code here works and I've got a bold byline and so now if that's all the bug ticket that was put in and that's all that I'm doing, then I will, I've got confidence that that byline is bold and I wrote and said, hey, page the standard m page primo byline is bold and again, this kind of circle back to the object during the CSS versus how we did sort of our BM The reason we do that is because I can just specify something like this while not messing with the html and having this code reuse instead of having to like write those h CSS classes once and then having to go through this html to kind of to direct that this is sort of why we wrote things this way.
So anyways, this is sort of the end of the training, this is kind of what I've got if you guys and then like I said, there's a there's a link to the pr here and a link to all the commits for for these things so that you guys can check them out this whole recording as well as the presentation is going to go out to you guys through list.
and then if you guys have any, like if you think of any follow up questions or something else that you kind of didn't get to or feel free to also if we need to like, if you want to ask, Liz and we can kind of feel through them to me and I can answer them that way, We can also do that.
So there was there's one last question that I kind of missed that what are the task to run the style guide in the same version as the as node and you are used for the build?
that's actually specified in the root of the project and build dot grade file.
I can actually show you that for the training repo it's in this build profile, you specify the node and yarn version in that in that great deal.
And that's what that's what greater will use those will download those versions and use those in the build.
so that's specified right there to make sure that you've got a good match or you know what no diversion, what all the versions grader is going to be using compared to what you're using locally.
so that's where that is.
Well, thanks everyone for attending.
And like I said, Liz will follow up with the presentation as well as the recording, and thanks for everyone's time.
Thank you tom