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.
Transcript
0:00
Morning, all attendees are in listen only mode.
0:06
Hi, everyone.
0:07
We'll get started in a couple of minutes here.
0:10
We're just waiting for everyone to get logged in.
0:12
Thanks for joining.
1:47
All right, I think that was I think that's basically the kind of good enough to let everybody join and we'll go ahead and get started.
1:57
can just making sure audio is working, Liz.
2:00
You can hear me pretty good and you can see my screen.
2:03
Yep.
2:03
Perfect.
2:04
Right on.
2:06
So welcome everyone.
2:09
So my name is Tom Hoppe. I'm one of the front end architects here at Brightspot.
2:14
And what we're gonna do today is go over basic, I mean bright Brightspot, front end training, basically kind of the cliff notes of how front end works here at Brightspot.
2:28
And we're not gonna get into like super in depth into, into like into code are gonna get a little bit.
2:34
but it's kind of meant as sort of an overview to sort of describe all the different aspects of doing Front end here.
2:43
So our agenda is as far as we're kind of gonna go over the, the, the stack and talk a little bit about like what front end means here.
2:53
We'll get into this, what we call the root style guide in our, in our view system.
2:58
We'll talk about the style guide application that we have, which is, you know, a way for us to locally develop.
3:04
We'll talk about the front end bundle and kind of how all of that all of our code gets kind of bundled together and then go over a little bit in not quite like in depth, but dive just a little deeper on to each of the three major portions of our front end handle bars for rendering javascript for making site interactive cs S and styling.
3:28
And then we'll talk about how kind of json is used throughout our front end stack for examples, configurations and et cetera.
3:39
And then we have a couple of small code examples at the very end just to sort of summarize everything we talked about and show it more as of an example instead of just in the presentation.
3:53
So really to get started, you know, what is front end here at Brightspot.
3:58
So for us, it's everything you'd think of as a front end developer.
4:03
You know, you work with html, work with templating cs S and javascript.
4:08
but one of the sort of additional things that we get to do as front end developers here is we help create the views, which is really we determine the data that we need to show on the website and we tell our back end team of what, what that is.
4:28
And also we're able to incorporate publishing features into Brightspot with just front end code.
4:35
That's what we'll get into the JSON configuration and how that works a little further down.
4:41
But normally, you know, like back end developers are modeling modelers or who sort of create modules in the C MS.
4:49
But here, we've got some controls on the front end to apply some publishing features and let and let editors sort of control the front end of the site inside the C MS.
5:01
So that's kind of unique.
5:03
And then, so for our front end stack, we use JSON for configuration files and to deal with those with those views and those generate those views in the with the JSON schema, we use handlebars to do html templating.
5:22
In the end, all of the everything in Brightspot lives as JSON.
5:26
So we use handlebars to turn that json into HTML.
5:30
We use less as our CS S processor.
5:34
There's no real reason that, that has to be used over a but in our sort of out of the box Brightspot go product, we, we use just less because that's what we're kind of familiar with.
5:49
we use javascript where we write natively in ESC six syntax and then we use babble to trans that to whatever browsers that this site needs to support.
6:02
But that way, all of our stuff lives as a native javascript with ESC six syntax.
6:09
Again, there's no real huge reason.
6:12
We wouldn't use something like typescript or anything else like that if, if we needed to.
6:17
But again, sort of in our sort of default bundle.
6:20
We're still, we're still using javascript.
6:24
We use web to create our modules and to create all of our bundles.
6:29
And basically, you know, create that build, we use yarn to deal with our workflow and to and package Js sorry package that Jason and to pull in all of our external packages.
6:44
And we use node when we run the local style guide and the style guide is our application that we use that runs in the background and runs on local host.
6:56
And that allows us to essentially simulate what the C MS is doing locally so that we can develop much faster locally versus having to develop and then upload to either a local C MS instance or to some kind of, you know, a hosted C MS instance in order to see our front end code.
7:17
So we'll get into how that works in a little while as well.
7:22
So we're gonna start this thing off by talking about the root style guide and we sort of refer this to sort of like as the glue between the back end and the front end.
7:30
And what, the Roots style guide, the reason it's called the root is it originally lived in the project route?
7:36
But we actually moved it into the front end folder.
7:41
just because it, that's where I actually makes sense, that's what it's doing.
7:46
But what the Roots Style guide does is it specifies the views which are a collection of fields that you need as a friend and developer to display the the site.
7:59
So a, a field could be such like like a headline and a subhead line in an article.
8:05
Those are on an article page, those are like 22 fields and we specify these fields in these Json files.
8:14
And each view requires that Json file with the collection of fields and a handlebar file which is empty, but it's really a render hook because that Json file specifies what its template and what its render is.
8:28
And then that H BS file is there to be the render hook.
8:33
And each of these views results in a java interface for the back end to implement.
8:40
And that gets automatically created on the build as the the view generator system goes through each of these JSON files and creates a view for each one of these things.
8:56
So as front and developers, we create this Jason schema in the field because that's what we know and what the data that we need to show on the site.
9:06
So again, for example, for an article page, you know, when you get the article page design, you might have a headline and a subhead line for the article.
9:15
So as front and developers, we would put that data into the into the view, we would create those 22 fields.
9:25
And then that's we'll get that when the page is being rendered from the back end.
9:33
And then what the backend devs do is they do the data modeling behind creating for example, an article inside the C MS, they create those modules and there's pages inside the C MS and then they create the view models that place that data into the views for us.
9:52
The contract between the front end and the back end is that JSON file because the, the way this whole system works is that creates the view.
10:01
And then we again as front and developers said we need this data.
10:05
So that's the data that we put in our handlebar files.
10:08
But what we as front and developers don't have to care about is really how that data modeling, how the modules work in the C MS and how that data is actually getting to us.
10:21
We really don't have to worry about that because the back end DEVS have to provide that data to us.
10:27
How they provide that data to us is basically up to the business.
10:31
Again, most of the time it's coming from the C MS.
10:34
where the back end devs created those modules of those pages inside the C MS.
10:39
But sometimes that data could come from some kind of back end or third party API could be whatever.
10:46
That's what we'll talk about in the back end training tomorrow.
10:49
But as front of developers, we really don't care how that data appears into the view.
10:57
what we know and what we care about is that, that Jason Schema is that, that's what, that's the data that we said we need up to the back end developers to how they're gonna provide it.
11:08
But what when we do get that data, we can then we can then work with it and we can show it on the website using the rest of the front end stack.
11:19
So we'll talk a little bit about the style guide application.
11:24
And what the Style guide app is is a no Js app that comes with Brightspot that runs locally and processes example, JSON view files using our actual handlebar renderers, the same ones that are gonna be used on the live site.
11:42
And that simulates what is happening with the C MS.
11:46
And it basically simulates the fact that data was entered into the C MS or however, the back end provided the data.
11:54
you're simulating the fact that that that view file was actually, you know, filled out by the back end.
12:03
And then it renders that on the web.
12:06
So it uses a DEV environment of web pack to compile all of our Js and CS S.
12:13
But that way, since it's a, it's a DEV en environment version of it, it's easier to kind of step through and go through because it's not like modified or or fully transpired.
12:27
And one of the main kind of advantages of this is it's since it's using the exact same code and the same build systems that the real site does, it allows us to work locally and then see the results of your work instantly.
12:42
There's Watchers running for both cs S and javascript.
12:46
So that when your stuff is saved in the ID E, it's automatically recoiled.
12:51
And most importantly, you have to trust that this is that since this is the same code, it'll work correctly once deployed.
12:59
So again, just to kind of summarize, we basically create some example, JSON files that essentially simulate what the C MS is doing a lot in live.
13:11
But then you're processing, use it, using it, your real handlebars and your real javascript and CS S.
13:18
And again, that allows us to work super fast locally without needing to run a local C MS instance and needing to like compile our code, push it to the C MS instance every time you make a small CS S change, so you can see all of your work instantly.
13:37
So now we'll talk about kind of the front end bundle and all the different sort of things that go into it.
13:43
We originally call this thing a theme, but the word theme is a little bit kind of diluted in what the heck it means different things to different people.
13:51
So we sort of renamed it to the bundle, which it really is, it's just a bundle of all of the front end code that goes to create the site.
14:00
So it's really the whole front end of the site.
14:04
It's everything that we basically work with as front end devs.
14:09
And for us, the, the default bundle is a whole bunch of handlebar files which do all of the html rendering.
14:18
Most of the time we use javascript just for site interactivity.
14:24
There's absolutely cases where we work with full javascript frameworks like VV level frameworks and state frameworks like something like react where we use graph QL end points to render portions of the site.
14:41
But a lot of the times we'll use that for big heavy applications that are contained within the site.
14:50
but not for the entire like you know, running the site full headless and and, and rendering the whole site that can absolutely happen.
15:00
But then the whole the bundle and the whole stack kind of shifts from handlebars doing the rendering, and javascript doing the rendering.
15:07
But again, most of the time and, and definitely in our sort of default, like out of the box Brightspot product, We use H BS handlebars to deal with the html rendering.
15:20
That way that HTML is there, it ends up going through and getting, getting cashed.
15:26
And not, it only gets rendered sort of the first time that a user or someone look pulls a page.
15:32
But then after that, it gets cashed, javascript comes in over the top and makes the site interactive, think something like carousels or menus or whatnot.
15:42
The all the CS S styles that are built from less for all the styling.
15:48
whether they're, you know, instantly, whether they're like linked in the page or some dynamically loaded CS, all that stuff in the bundle.
15:56
We've also sometimes times we have assets such as some SPG icon, iconography or some other static image assets that we don't want in AC MS.
16:06
You know, it's kind of few and far between.
16:08
most of the use case for this are might be like SPG icons or things like that.
16:15
And then the bundle is gonna have a bunch of Jason.
16:18
These are both the, the all the view examples for the local style guide, as well as all the configuration files for how that front end bundle is going to interact with the site and interact with the C MS.
16:30
We'll so we're gonna do is like go into a little bit in depth over each one of these and kind of show a little bit how, how they work and how kind of we work with it.
16:42
So we'll start with handlebars.
16:45
We use that again as our templating language to convert Json to html.
16:51
It provides a nice strong separation between your template styles and javascript.
16:56
While that like, you know, separation is not super duper important, it is kind of nice having that that like, hey, this is, this is how your html is rendering your styles and Js can be a little bit separate from that.
17:09
And while it's defined as a logic list templating language, we found that having a few bits of extra helpers really help out in composition of templates.
17:23
we created some helpers for doing some comparisons, some logical helpers, little bit things like math and some string manipulation.
17:36
And then we've got a option that you can create your own helpers via javascript where you can feed the data from the handlebar file to a javascript helper and run some, you know, run whatever kind of logic you need on that.
17:51
If you really need to, a lot of we would, we would push to have, if it's heavy logic, we would rather have that on the back end and have that done in the view model.
18:01
But depending on what it is.
18:04
again, I haven't, we do have that option to create your own helpers.
18:08
There, there's a link in here to a comprehensive collection of all of the helpers that come out of the box with a Brightspot.
18:16
But I'm gonna go through a few of them here and kind of talk about.
18:21
So some, some of the highlight ones.
18:25
So, like I said, we've got some comparison helpers that are not in handle bars by default.
18:31
They're, we, we found that these are great for moving through item arrays with, if you need a little bit of logic or some conditional rendering or conditional formatting, something like equals greater than less than and or while these are really useful for you know, again, moving through item arrays and index based things.
18:55
We sort of discourage using these for like string comparisons and things like that.
19:01
While it can be done, it can lead to just like a little bit too much logic into your, into your templating.
19:09
And again, that kind of stuff should sort of be reserved for back end.
19:13
We have two very important helpers that we kind of have use all over the place.
19:19
And it's the set and get helpers.
19:22
Since we have a, a kind of large tree of parent and Children templating in a page where you know the page has a top level render and then something like a like a module is gonna have its render then then down to like even an image render that is a, a number of levels deep inside.
19:45
we needed a good way to pass values from parent to Children templates.
19:50
So the set and get helpers allow us to do that where on a parent level you can set some variables and then Children can react to those to those variables via get.
20:05
And this allows for a lot of template reuse.
20:08
So that's kind of where we use this.
20:10
And I use the example of you know, an image and a a module above it.
20:16
Whereas something like our image render is a pretty generic render that's used all over the site everywhere.
20:24
And then we use set and get to deal with the image sizing of that image.
20:30
I I'll get into it.
20:31
There's a little further down.
20:32
There's a better example of this that I'll get into.
20:36
We've also got this include helper which literally includes another template within a template.
20:45
It passes it the current context or the current data set that it's working with.
20:51
so that you can have good template reus throughout the site.
20:57
So for example, that image render is something where something I can include might be used or something where you might want to create.
21:06
Like we have out of the box, we have one render to, to render a link and just a simple A HF And we call it the link dot HPS file and we'll use that all over the place when we want to create a link.
21:20
and pass it some data instead of having to literally rewrite a every time and then forgetting the one of the one of the attributes like forgetting to deal with the target or whatever, like that's not there.
21:32
That's not a thing because we use include to to do that every time.
21:38
And we, we have this render helper also.
21:41
And it's kind of a little like a brother to the include.
21:44
But it's a contextual rendering concept.
21:48
It many of our templates have different what we call styles but different visual variations of a template.
21:56
So for example, if we have a list of items, you can display a list of items, number of different ways.
22:03
A list of items could be displayed as a grid, as a carousel as you know, whatever as a single as a straight vertical list.
22:12
And there, there's a concept that allows us to basically render a specific style of a template unless an editor chooses an override.
22:22
So for example, if you wanted the first module on your homepage to always be a carousel, you can use this kind of pattern to where if if an editor adds a list to the top of a home page, it automatically gets rendered as a carousel every time unless they override it.
22:42
So kind of it's a concept that allows us to create a little bit of a easier editorial experience.
22:49
So you'll see that used throughout some of our out of the box stuff.
22:54
Then we have a handle bar helper that we created for image sizing.
22:59
And then we have this which is a dynamic image sizing system.
23:08
And the resize helper is a directive to receive a specifically resized image from Dems.
23:15
We use this essentially everywhere we use, we create imagery because we set a, we create an image size JSON configuration file that has all of the different image size options and crops that are gonna be available.
23:34
And then we resize images to that specific crop.
23:39
We use this with set and get a lot of times to allow again for code reuse and contextual image sizing.
23:46
So I'll show a couple quick little code snippets of this.
23:52
Whereas we have one image tag dot H BS which is used all over this, the, the place.
24:00
And here you'll see the resize helper.
24:02
Oops, sorry.
24:06
Too many clicks we have this resize helper here that resizes an image to a certain size and you can kind of see it using the get helper here.
24:18
And then there's one more helper called the Fallback helper.
24:22
which if a specific get fails, it'll fall back to a string.
24:28
So the way this code ends up working is we have, you know, one image tag that's used all over the website, it will resize an image to again if a parent has set that otherwise it'll fall back to just like a generic 16 by nine image if you don't specify an image size.
24:48
and something like a recipe module here uses this exact pattern where it basically says here's my image.
24:56
And for the image, it's going to set an image size of medium four by three because we all want a 16 by nine image in our recipe model based on the design and then it'll just defer the rendering to the to that child image.
25:13
And then that image will basically render itself with a four by three image instead of the default 16 by nine.
25:20
So this is kind of a pattern you can see throughout.
25:23
but this again, we like this because it supports that template reuse of allowing this, this code to be basically this image code to be used all over the site.
25:34
But the image size to be changed per instance that it needs to be changed in.
25:42
So that kind of goes through all of our handlebar examples.
25:49
So now you got a bunch of html.
25:51
So now we're gonna talk a little bit about our javascript.
25:55
where again, we use javascript to mostly to make things interactive.
26:01
It's es six written javascript.
26:04
It's a mixture of classes where we need like base classes and then some stuff on top and custom elements.
26:13
A lot of we basically use the custom element pattern to instantiate our javascript.
26:20
so that our javascript is tied to a Dom element.
26:25
And when that Dom element gets placed in the Dom, you know, the custom elements are supported, you know, are pretty ubiquitous.
26:32
So that's how we instantiate our javascript instead of trying to have some kind of monolithic Js where we need to go through and like scan the page and do things like that.
26:46
We use these we use custom elements most of the time to in our javascript.
26:51
Again, we use babble to trans file that es six into browsers.
26:55
We need to support, we've got a browser list file that can determine that.
27:01
So based on that Apple can trans it as much or as little as it needs to.
27:09
And then we package our javascript using web pack into a combined javascript.
27:15
That kind of goes out to every page as well as chunks that get dynamically imported.
27:21
So those chunks can be something as as simple as taking some third party large javascript code and doing a dynamic import on that inside of our web pack and then web pack will automatically chunk that out separately and only pull in that javascript when necessary.
27:43
So for example, this is something we use in our carousel code where we use Flic as a third party library to deal with all of the interactions of a carousel.
27:56
But we dynamically import Flic.
27:59
So that means that if your page does not have a carousel on it, such as like an article or something that Flic library isn't loaded on that page.
28:11
That Flic library dynamically gets loaded.
28:14
when the custom element to deal with the carousel gets loaded, Because the HTML for a Carousel is on the page, then that will dynamically load that chunk that web pack automatically creates.
28:30
And again, we can use this sort of pattern to dynamically load this javascript and kind of make that initial, you know, we want to have this initial javascript file contain all of the code that is, you know, based on all the pages for, for a faster load time and for cache.
28:51
But to create some efficiency, if you've got a bunch of javascript that is not used on every page, you can dynamically pull that in whenever you need to.
29:03
again, we use custom elements to bind that javascript to the Dom.
29:08
And then for most content driven sort of I put in quote static websites, there really isn't a need to load a full javascript framework to sort of deal with things like if use because we're dealing with that through handlebars, There is no state or sort of used to handle so that full javascript framework is just sort of overhead, that's not really necessary.
29:31
So we want to create a performance site.
29:35
But if this allows us to use javascript and make the site more interactive and sort of enhance the html versus using it for rendering.
29:44
Again, that's not to say that we don't use frameworks or we don't use something like react with pull in data from graph QL because we absolutely do.
29:54
But again, we reserve that for more things that are more application based.
29:58
a good example for this could be like a sports site where you know, the article that has to do with a player or something like that or an article or like a team page which has information about the team.
30:14
That is seo is a heavy consideration for that.
30:19
So we don't, we want to go ahead and have that be static html, that's cash that's crawled, that's etcetera.
30:25
And it's easily rendered and it's fast but the scoreboard or like a leader board of an event that might be happening right now.
30:35
That's something that sort of enhances that page and that's something that makes total sense to have as a React application that's hitting a graph QL endpoint that pulls every minute and updates that leader board.
30:49
So the way we'll do that is that React app will be a custom element that is bound to the dom that can then dynamically load react if it's all, if it's not when it's necessary and reload that application, go off, hit graphical end points, go ahead and render itself as you know, basically a deal with its own javascript rendering, deal with the views.
31:15
Whereas again, the rest of the, the page is sort of static content which is driven from the C MS and processed through handlebars.
31:25
But they're getting back a little bit to that javascript custom element.
31:28
There's an example that I was talking about with the carousel code where the carousel code is super light to because most of the work we outsource out to quick flic, but you can see here where we have an await dynamic import of Felicity.
31:46
This is the directive that web pack will use to chunk out Felicity.
31:51
So what you see the 40 lines on this screen, that's what's getting compiled into your main javascript file.
31:58
And then that's what gets, you know, this connected callback is what gets triggered when a carousel is detected on a page by the browser.
32:08
And then it dynamically imports Felicity.
32:10
So we, we use this sort of pattern to keep our main javascript lighter but still be able to use third party libraries when we want to.
32:23
So that's what I've got for the javascript.
32:26
Now, we'll talk a little bit about our our kind of CS S patterns and, and our styling like I said, we use less as the CS S preprocessing.
32:36
There's nothing in Brightspot or in our build systems that requires less versus SASS.
32:44
We just chose that a while a while ago and we really haven't changed the SAS because it's essentially, you know, less and SAS are basically doing the exact same thing, same thing, which is pre process, right?
32:57
Letting you write basically you know, that language and it, and it ends, ends up in the end getting processed into CS S.
33:05
Anyway, we use sort of a ben style syntax for class and element naming.
33:12
that's blog element modifier versus having like a full object oriented CS S framework, something like bootstrap or one of the other frameworks that's out there.
33:24
We feel that working with like AC MS working with a bunch of modules and a larger developer team, CS S changes and bug fixes are a little bit less likely to create regression issues as working with a be style syntax.
33:40
You're literally working with that block or that element and creating CS S for that.
33:46
Versus working with like a full object oriented CS S framework file.
33:52
And then that would that basically, you know, we essentially know what you're working with.
33:57
And that allows for multiple developers to work together a little bit more easily than having, you know, to someone that manages this O CS S library and then people that are sort of using it.
34:11
If you're creating if you're not working with the out of the box bundle, but you're making your own.
34:17
The world is your oyster in terms of how much what you can do, you can absolutely like, there's nothing that restricts in Brightspot, there's nothing that restricts what kind of styling you're doing, what kind of patterns you want to work with.
34:34
I am just sort of describing what we do in our out of the box bundle.
34:38
And what sort of are like quote unquote go to is but that's not to say that we don't use some object or CS S concepts because we do for some things that are a little bit more global in places where it makes sense.
34:53
We have a, we have a few of those concepts as well.
34:57
But we use there we go.
35:01
So we use descriptive names for modules and components and use kind of the ben pattern to name their elements.
35:08
We use less to abstract some styles allows us to sort of use less extends or mix ins depending on the use case to abstract some styles.
35:19
But we then do do a little slight bit of object oriented as well to sort of create some kind of global concepts that can be reused throughout html.
35:30
So we don't have to repeat the CS S a whole bunch.
35:33
So an example of that is like the page, like a page list for us.
35:37
A page list is a very common content type.
35:41
That is essentially a list of, of pro we call them promos.
35:45
So it's a list of elements.
35:47
And so, this, a page list is something, that's used all over like section pages and home pages.
35:54
So that could be a carousel of news stories or a grid of news stories or a list of new stories and all these things a lot of times have a bunch of common elements.
36:03
So a page list might have a footer and it might have a call to action and it might have a set, it's got a set of items and it's got a header or something like that.
36:14
So these things we kind of create this sort of object oriented like OO CS S kind of page list footer where this html can be used reused directly.
36:25
But then for things that are not common between all the different page lists, this is where we create instances or versions of them with some the, the, the modifiers where this is a page list, it's a standard a page list.
36:42
We kind of use these names out of the box.
36:44
We I think naming things is probably one of the harder things when you're working with, with code or with module or with like instances of styles.
36:54
So instead of trying to create fancy names like page list grid for across or whatever, we just we just call them A through Z and then we use the display name option or configuration files, which we'll talk about later.
37:10
So you can, you can create a more colorful name for your editors if you need to.
37:15
But for the developers, we just went through the, the alphabet.
37:19
But this is where you can create and you can write some CS s for certain instances of of these lists to have the styling done done here.
37:32
Rather than creating like fully object oriented CS CS S where you just distribute those classes throughout the html.
37:40
This is the kind of pattern that we work with, with the out of the box theme.
37:47
We use CS S variables to allow us to set values whether they're in CS S or in line html.
37:56
This allows us to create this nice pattern to set these CS S variables at the root level through C MS editorial fields.
38:06
And that allows us to create to allow for customization by editors.
38:11
We use less for places where variables are helpful, but editorial overrides are not necessary for something like Z index.
38:20
We just use it, we just use less variables.
38:23
There's no reason we should use CS S bars for those and we might actually like transition from less bars to CS S bars for those later.
38:31
But really less far is just definitely do the job there.
38:35
But again, for a lot of things, we do use CS S bars and a to show a little bit of that pattern.
38:44
Something like colors is a perfect spot where we want to allow editors to set these colors through the C MS editorial interface.
38:57
So we have this colors HPS file which is a handlebar file which takes variables that are coming out from the C MS that editors can set such as primary color or a primary text color.
39:13
And then it'll create an in line root style sheet with these with the, with setting these CS S variables.
39:23
And then now we have a less file that pulls in the next level of those where it pulls in those variables that got set by the handlebar file and actually sets the CS S variables that are used throughout our code and then creates a fall a little bit of fallback for that.
39:41
So basically, if an editor sets a primary code inside the C MS, this variable will be set and then it will be used for the actual primary color.
39:53
But if the editor does not set that we've got like a fallback for that, that we can create you know, a, a color palette in our code.
40:02
If the editors don't make any choices and then this color primary for example is what's used actually color header backgrounds.
40:12
The example that I have where like the white header background, unless the editor chooses a different color inside the C MS, this is the variable that's actually used throughout our code.
40:23
And you can see it in the page header, CS, S or page head or less that CS S variable sets the background of the color.
40:31
So we use that pattern throughout for dealing with things that again are changeable by editors such as colors, things like topography and fonts.
40:42
We use that as well or font sizing where like an editor can go in and determine some different font sizes for a certain list or something like that.
40:51
We use this pattern for those places.
40:56
So, let's there we go.
41:03
So that's kind of it, it on the CS S like I said, we don't really dive too deep into these in this presentation.
41:10
But all of these examples and everything is in the training repo And all of these links will be sent out if you want to dive deeper into this stuff yourself.
41:23
So we'll talk a little bit now about Jason.
41:26
We use that throughout our bundle versus whether it's these view examples that are in the style grad application which I'll talk about.
41:35
or a lot of like for most of our Json also is all of our configuration of how that bundle interacts with the C MS and interacts with the site.
41:46
So json for view examples to it, we use this JSON to simulate how the C MS is going to fill out the views.
41:57
So again, this also, this essentially allows us to simulate what an editor is doing in the C MS and allow us to create examples of content type and even entire pages locally.
42:09
So then when the style guide application is, is run, it's processing this json using the handlebar files that are the same handlebar files that will be used when this bundle is uploaded to the server.
42:25
So that way, you know, you can simulate what the heck is going on and we'll these are a few examples of these sort of JSON files, view examples.
42:41
So page dot JSON is sort of our kind of route and like every page has all of these JSON file, Json keys and this is the view of a page where it has you know, things like a, a language attribute that might be used in the head.
42:59
And the title description, it's got a, a logo and it's got some navigation, social icons and that this is sort of the, the main base of what a page has.
43:13
And then something like an article page.
43:16
It leans on top of that page that Jason because it includes all those things that a page might have, but it has things like a headline, a subhead line, some authors and an article body.
43:28
So these are the views that we we created in that root style guide.
43:34
And these are examples of that view filled in by an editor to again, essentially simulate what's happening in the C MS because if you could have an article page that's created in the C MS like the and the headline are all going to be filled in by editors.
43:53
But here we have these little text generator helpers that we have that allow you to basically insert random words for the headline and, and random words for the subhead line and a random date which allows us to not only like view this stuff locally in the roots style guy with these kind of fake words, but also sort of stress test.
44:14
our TML and our design with this kind of pattern where we can say, hey, insert between five and 15 words per reload of this page.
44:22
So every time we refresh, we get a different headline so we can see how you know, our HTML and our design reacts to a short or long headline.
44:32
And this sort of pattern continues where, you know, we can insert paragraphs in the article body and include some enhancements as examples to simulate an editor, adding these enhancements.
44:45
But here we can view this instantly and see it in our local style guide.
44:52
Furthermore, we have a pattern to allow us to pull down already existing pages in the C MS using a query string directive to, to see this.
45:06
And I guess I can show a, a quick example of this pa if this where if you pull up one of our pages with this render style guide designator, this creates this same exact this creates sorry, not the same guy.
45:27
This is the JSON representation inside the C MS of this particular page.
45:34
So this allows you to even pull down like a live page into your local instance.
45:40
So if you needed to troubleshoot something or whatever, But this is the JSON representation of this page and this entire Jason Blob could be pulled down to your local style guide and this home page for a Brightspot could be rendered locally in your local style guide instance.
45:59
So that way you could, you know, do some local editing and local code editing super fast and see your results instantly.
46:08
So the we also, so I guess that, you know, again, you can create these files manually or these files, you can pull down like if you already have a production instance or a page that you're trying to troubleshoot or a page that you're trying to get an example of in the, in that local style guide application, you've got a couple of different ways of getting this JSON.
46:30
But again, the, the main point is that Jason gets down into your local your local bundle and when local style guide is run, you can see these things real time, which is super helpful.
46:45
So we use JSON file, json all over the place to set these also configuration files.
46:52
They're the mechanism that define how the bundle interacts with Brightspot and actually the style guide application as well.
47:01
These config files have all of the configuration for image size options.
47:08
Like we talked about additional fields that the front end can added to the MS because we kind of talked a little bit about the sort of how we can allow editors to, to sort of control that front end using something like those color variables or some other front end fields that we'll talk about a sec.
47:27
The style variations of content types also.
47:30
So like we talked about like a, a list of things can be interpreted as a bunch of different ways, whether it's a grid or a carousel.
47:38
So we create sort of instances of these content types and then editors can select those.
47:45
and then configuration options for that style guide application So we kind of configure that style guide app to show like a navigation.
47:52
So we'll talk, I'll show that also in a second.
47:56
So configuration files may be defined at the root of the style guide or a subdirectory.
48:04
We can have the best practices that we like want to put those configured files local to the components.
48:10
And the global configuration file lives in the root of the style guide directory and at run time and during the build, all these everything that's star dot config dot JSON actually just gets combined into one giant Json file.
48:25
And like originally a long time ago, we actually had all of this just as one configuration file, but it got to be sort of a merge conflict mess, which is why we did this concatenation of all these configure that JSON files at the end and, and sort of distribute them down into the sub subdirectories where they make sense.
48:44
So something like the image size options are defined at the root because those are kind of global.
48:49
But then some style variations of a page list will end up being going into the page list folder.
48:56
Because then that kind of that makes contextual sense of where to look for those.
49:03
So we'll talk a little bit about the image sizing.
49:06
We can kind of dive dove into it how that resize helper works.
49:09
But image sizes are defined in a configuration file in the root.
49:13
And then to define an image, you're gonna need at least a width or a height or a maximum within a maximum height if you want sort of dynamic resizing.
49:25
once these are defined, these are then what's used with that resize helper to fetch those images from Dems.
49:35
And this is where you'll also CRE create designations if you want to use like web P versus JPEG, if you need some source set, descriptors are like that for your image.
49:46
But this is where you know we define and we say we call a small 16 by 9, 100 by 57.
49:53
And for that one, we do want web P images served.
49:56
We've also got patterns that allow us to do dynamic widths and heights and cropping based on.
50:04
So for example, where's there?
50:09
a here's a good example of a 14 by 40 width image and it's a not a fixed aspect ratio.
50:17
So this will create a 14 40 pixel wide image.
50:21
But since there's no height designator in this image size, it will will pull the height of whatever the original source image was.
50:33
So if a giant square is uploaded into the C MS by the editor and this image size is picked for a particular module, it will turn a 14 40 by 14 40 image.
50:47
this preview height, the preview kind of designator is used just so that their local style guide can kind of see an example of something.
50:58
So it sort of knows to to render something.
51:01
So this is only going to be used for your local style guide application to make sure that this image can be shown since there is no C MS in a source image.
51:10
but this kind of pattern can be used.
51:13
And then something like we you can also create something like a maximum height and a maximum width without having a width and height.
51:23
And this will purely resize the image based on the longest dimension based on the low based on the aspect ratio that was uploaded by the editor.
51:34
So you've got lots of patterns to kind of deal with with aspect ratios and what's uploaded into the C MS.
51:40
But all of this is defined in this image sizes, configuration file.
51:44
These image sizes are given names and then these names are what is used in your handlebar file with that resize helper to fetch the right image from you when the site is rendered.
51:58
And then this is where we get into like adding editorial fields into the C MS as front end editors, I'm sorry, as front end developers.
52:07
So we can specify additional fields that are added into the styles tab of into the C MS which allows editors control over those styles of content types.
52:20
These fields only persist within this data bundle within this front end bun bundle and they're not part of that content types data.
52:29
So that's a pretty important distinction.
52:32
because again, these fields are really meant to be used by editors to add certain styling or visual elements to this data.
52:45
They don't actually manipulate that content's data.
52:47
So what this means is these are very useful for additional styling options such as background colors, image alignments, dealing with the number of columns that a grid might show.
53:00
but these shouldn't be used for data.
53:04
So for example, you shouldn't use something like a front end field to add some text.
53:10
Unless that text is some purely visual flair, I wouldn't want to have a subtitle or a subheading of a module be created with a front end field be before.
53:22
Because if I had a piece of data that's like a subtitle, I want that to be with that content types data, I like to say for clients that like a, a good way to think about this is if you had a feed of your site like it, simple as RSS feed or complicated as whatever other feed there might be to some third party source.
53:44
If there is, if you want something to go in that feed and you're working with a variable that should be in that feed that should be a back end field that belongs in the view.
53:56
But if some piece of config editorial configuration like a background color and an image alignment, some data like that is that not useful or necessary in a feed of the data?
54:08
So that's a perfect thing that could be a front end editorial field instead of needing to be a back end model data field.
54:19
So what we have is a fields config file where we specify a bunch of these front end fields.
54:26
So you'll see something like a header, text alignment in here or whether you want to like have a a number of columns for this field, whether you want to be full width or 55th, like how many columns do you want on this?
54:44
If we have an enhancement alignment, What do you want, how do you want to align that enhancement?
54:51
Do you want it to be centered?
54:52
Left, right, full width or whatnot?
54:56
These, these are like perfect examples of front end fields where we want, like how fast do you want this carousel to slide?
55:04
And we put that in in seconds.
55:05
So you can actually type in a number and that'll be that, that'll be given to the javascript to control that carousel speed.
55:12
Sound like that is not necessary at all in a data feed of a module that has a carousel, but this allows the editors to sort of control that carousel speed.
55:21
And it allows us as front and developers to add that into the C MS as an editorial field.
55:26
So you can get that feedback from editors.
55:28
So you can then use that in your handle bars and use that in your javascript.
55:33
So for example, a page promo module is a a promo module for us.
55:41
in Brightspot is something that promotes a piece of content and promotes it by having like a title, a description of usually an image and a link.
55:50
So we have you know a number of these promo modules A through C here.
55:56
And these are a bunch of the fields that we as front and editors have added to configuring a page promo module where you might want to hide the category, you might want to show the byline, you might want the toor to be able to set a specific image aspect ratio.
56:13
align the text center like right set of background color in that module, maybe inverse the text on the on that module.
56:21
If they choose a black background color, they might want to inverse the text and you know, you could animate module and scrolls down into the page.
56:30
So these are the kind of things that again are front of front end visual extra fields that can be defined by editors that don't necessarily need to be added to the data for that module.
56:45
But they are kind of visual that we might want editors to mess with.
56:51
So that is again, one way we can add editorial control over some styles.
56:59
And another thing is the JSON configuration for the styles of content types.
57:05
So this is a powerful concept that lets us create many different looks of a content type by using the same data scheme.
57:13
So for example, like I, like I talked about where we have a page list, a page promo and a page promo module content types.
57:22
And these are content types that are used to assemble a lot of pages that are sort of modular pages that are, that drive users to content, something like a home page or a section page.
57:34
Our page list is for us a a list of promos and a list of promos can be displayed visually a large number of different ways.
57:49
And we happen to have you know, 20 something ways of showing that whether that is that could be a grid, that could be a carousel, that could be an in line list.
58:00
This is where we create handlebar files to create the html, to take the same content type and the same data schema.
58:09
But show it a number of visual ways and we create this configuration file that lets editors choose which styled variation of that content type they want.
58:25
So they might add a module to the top of the home page and then they're gonna go into the styles tab and they get all these different choices to, to choose from for how to visually lay out that particular set of data.
58:41
And that concept applies to literally every module that in every content type that's in Brightspot.
58:50
So you can create maybe two different styles of an article.
58:56
You can create multiple different styles of a page list, multiple styles of a page promo of even a section page could have multiple different front end styles.
59:08
Which, what that means is that a section page content type could be rendered using different handlebar files to have two completely different looks and feels if that's what the design and your product people and your editors call for.
59:25
So this sort of concept is pretty powerful and it's used sort of all over the place to again let editors control visually.
59:33
How?
59:38
Right.
59:41
So I think that that sort of goes through and is the kind of basic outline basic kind of cliff notes of front end.
59:51
And where I wanted to go now is to just show a couple of code examples of of these different things.
1:00:01
And we've got two specific code examples.
1:00:04
One, The first one is gonna be, talking about the front end for a recipe page and a recipe module.
1:00:12
this is sort of our, kind of exercise and like our training exercise that's in the training repo,, that you'll get links to, this whole presentation by the way and this repo.
1:00:23
and all this, all these links kind of go out in, they'll go out like, I think next week or something like that.
1:00:31
My Liz will send those out to everybody.
1:00:35
And so what I'm gonna do is we have a, we created this recipe page and recipe modules which you'll go through and and Brennan and the back end training will kind of talk about creating some of the view, some of the models and the view models for the recipe page and the recipe module.
1:00:58
But here I'm gonna show a little bit of code around how you can create like when you're creating a new content type, how you're gonna do that on the front end.
1:01:09
So, the first that we start off with, we work with the back end team as well as the product team as well as design to determine what the recipe and the recipe module.
1:01:21
JSON will look like that.
1:01:23
We wanna know what the view will look like, this will establish the contract between the front and the back end and that is placed in that root style guide.
1:01:32
So basically before the sort of the front end really starts their work, we will determine this these views, right?
1:01:44
We create the view specifications that goes in the root style guide folder, it for this particular case, we're creating a recipe content type and then there's a recipe article page and then a recipe module that can be placed in places.
1:02:00
So we will create this recipe article page Jason.
1:02:06
And it is a creative work page which means it's a certain type of page that already brings in some concept.
1:02:14
So that already has all of the page json associated with it that brings in all the things that a page needs.
1:02:21
But then a recipe article page also will have it'll have a lead that an editor can add because there might be like an image or a video lead.
1:02:31
It'll have an article body that the editor can use to describe that recipe and then it'll have the recipe itself.
1:02:41
And then, so we create these as when, when we create these JSON files, we're creating that view that tells the back end that like somehow you've got you as back end developers have to give a lead, an article body and a recipe to the front end.
1:02:56
And then the recipe module is a sorry that a recipe module then is a totally new content type.
1:03:07
It's not actually a page, it's just a module.
1:03:10
And with that module, here's the data fields that we determine together, you know, based on the design or based on what the product team wants that an recipe has.
1:03:19
And it's gonna have a title.
1:03:20
It's got an image.
1:03:22
and then some properties like difficulty, prep time, cook time, it's got a list of re and some directions.
1:03:30
So we've determined that these are the fields that we need to show a recipe.
1:03:37
So then we're gonna create a handlebar file that uses all of these fields.
1:03:42
And then, but we as front and developers again, we don't care how these fields get to us.
1:03:48
We just care that these fields are gonna be there because we know that we need these fields to show a recipe.
1:03:55
So once we have these o once we have these views set up, then we can take the following steps to actually create the actual front end.
1:04:05
So what we're gonna wanna do is we'll, we'll add a JSON example for ourselves and the handlebar renderers to deal with that recipe.
1:04:16
So you notice that this is in the bundle instead of just the root of the front end style guide, We create we've got the same recipe folder here and we create some jasons that are the examples of what these things would look like if they're filled out by editors in the C MS.
1:04:39
So start with a simpler one, which is a recipe module.
1:04:43
And this is got the render associated with it.
1:04:47
And here we put some test data in to kind of simulate an editor, filling out a title, adding an image and you know, so we can, we could have used the words helper here or we can just write easy, it doesn't matter.
1:05:01
And then for the ingredients, we simulate again, the editor adding a list into the RT E here.
1:05:08
This is what it would look like.
1:05:10
And you know, again, we got the rest of these fields filled out here.
1:05:14
And then it's the same thing for an article where we create an example, we've already created like a root example of an article page that already has all of the other fields kind of filled out with examples.
1:05:29
But what the recipe article page has differently is it's got we just created a very straightforward article body instead of creating a giant one with a bunch of enhancements.
1:05:41
But so it just simulates that an editor, put a couple of paragraphs in to describe the recipe and then they added the recipe module into the recipe field that we created right here.
1:05:51
So now that we have these two jasons, we can create the handlebar files.
1:05:57
Both for the recipe module and the recipe article page.
1:06:01
So for the recipe article page, we kind of made that straightforward because it really kind of looks and functions and works exactly like an article page.
1:06:10
So we actually the handlebar is straightforward because we just included the article page using that include helper.
1:06:17
Oh Sorry.
1:06:18
using that include helper.
1:06:21
we can actually literally include this code into this handlebar file.
1:06:26
Since we determine it for our design, it looks exactly the same.
1:06:31
We just want to reuse that handlebar, render the article page handlebar, render instead of pasting that code in here.
1:06:38
So that's a pretty cool pattern that you can create some code reuse around it.
1:06:42
But for the recipe module itself, this is where you're gonna create the HTML for that.
1:06:48
So we use that kind of block element pattern where we create a recipe module.
1:06:55
And then we use just standard handle bars to you know, create a difficulty at total time to render the image with a four by three image and then create a some ingredients and, and, and directions and whatnot.
1:07:12
But this basically lays out the html based on that JSON data that you're gonna get.
1:07:21
you'll notice there's a helper that we use in here.
1:07:24
I kind of described earlier but there's a format helper, a format helper.
1:07:30
allows us to use Java style properties files to localize text that we might not want in the CM.
1:07:38
Yes.
1:07:39
But we want to potentially include in many different languages.
1:07:43
So instead of we've got the Cook Time in our Jason.
1:07:50
but we want to put like a little heading that says cook time.
1:07:54
You don't want the editors to edit that every single time.
1:07:57
So we'll use that format helper to take the words cook time.
1:08:22
Because we, we never want to hard code that piece of text into the handlebar file because that would break localization if, if you did that versus using this format helper to deal with things like static text.
1:08:35
But again, so now that we're done with these things, we have a sorry, we've got the views.
1:08:45
Now we've got handlebar renders and we have some examples, Jason.
1:08:50
Then we're gonna wanna add some simple styling to that.
1:08:54
So for us, it's got some very straightforward styling or we just add a border to it, throw some margin around it.
1:09:02
And then we, you can see this less extend pattern that we use to deal with topography.
1:09:09
Where for us in our bundle, we create a, a large number of text styles and we name them like descriptions or subheadings or titles.
1:09:18
And then we just extend those less styles everywhere instead of pasting font size, whatever all over the place.
1:09:26
And then having to deal with the media queries of that, we do that once and then we use less extends to, to allow all those type types to be kind of distributed throughout the site.
1:09:37
So, we create some CS S to deal with that recipe module.
1:09:42
And lastly, we've got a navigational config file in the style guide which sort of creates the left side menu of the style guide application.
1:09:54
And we put that article page there so that we can view it in the style guide.
1:09:59
So once all of these things are done, we can run our local style guide obligation.
1:10:07
So I've got that running here in the terminal.
1:10:10
And once that style guide is run, if you now go to 80 80 which is the style guide, the left side shows that navigation that I was working on and there is that recipe right here.
1:10:29
which is that recipe article page which has the same look and feel as an article page because it's using that same handlebar render, but here it renders a recipe module and this is the recipe module.
1:10:44
This is that, this is all the data that we had in here.
1:10:48
oh sorry in that JSON file and the CS S that we created.
1:10:53
And again, since we're running the local style guide here.
1:10:56
I've got that, terminal running and I've got the style guide application running.
1:11:01
if I go into my, ID E and I go in and I edit my, recipe, I've got the handlebar file here, for the recipe module.
1:11:18
and I've got my CS S, in here as well.
1:11:25
oh, there it is.
1:11:26
I've got my CS S here as well.
1:11:28
So if I make changes to this, it auto runs the CS S and everything you, you've got the Watchers and you can see all of your code instantly and the effect of your code instantly in the local style guide.
1:11:48
So this is how you can develop super fast because you're changing your CS S.
1:11:53
this is run in the background again, if you change your html, you can see your changes instantly on your html, right here in your handlebar files and the same goes for javascript and the same goes for changing the data.
1:12:13
So if you, I wanted to, you know, stress test, whether, you know, how would 100 words potentially work inside my title?
1:12:21
I can do that and then I can see the results of both my testing of my data, testing my handle bars or testing of the CS S instantly here.
1:12:35
Yeah, in my local instance.
1:12:36
So, that's kind of how we create a new content type.
1:12:43
And that's how we see our changes super fast locally.
1:12:48
The other little code example that I want to show is making a new style of a content type.
1:12:56
So this will this will show let me step through real quick of again, a page list style, a page list is a list of promos that can be displayed a number of different ways.
1:13:11
Let me switch my branch real quick here locally.
1:13:17
And then I cannot show the style guide.
1:13:21
Let's see, we are got the branch switched.
1:13:26
And now so we have a a large number of lists on a site.
1:13:35
So for example, you know, a standard list a looks like this where it has one big promo, four of them without imagery.
1:13:43
And then a grid underneath.
1:13:45
A list can also be a grid this way it can be a you know, a grid.
1:13:51
This way it can be a vertical list, you can have 100 different styles.
1:13:57
But if for example, our, you know, for this, for the sake of this exercise, a our designers have decided that they want another style of a list.
1:14:09
And it's gonna be one large image and then a grid underneath it of smaller list.
1:14:16
So if you have a, if you have four or let's say five different promos that have been added to the list.
1:14:22
The first one's gonna be large, the next four are just going to be displayed in a two column grid because none of our current examples have that, you know, we might have like a one and we've got the three column one here.
1:14:34
We've got some that look like this, but we don't have like a kind of straightforward one.
1:14:38
So the way we would do that is we would go ahead and we create our kind of step one is we'll create a page list standard M because we already have all the letters until then taken.
1:14:54
So we will create the next one, then a list, which is a page list standard M.
1:14:57
So we're gonna create the handlebar file and a JSON for it.
1:15:02
So the JSON, we say that it's a page list as a template.
1:15:07
But the styled template is actually gonna be, that's the style template that the editor will choose is page list standard M.
1:15:15
We're gonna give it a title.
1:15:16
We're gonna give it some CCT A and we're gonna simulate that an editor has put nine promos into this particular list.
1:15:24
So that's the JSON for page list standard M.
1:15:27
Then we're gonna create the handlebar file for it because that's the style template that we, that the name that we designated here.
1:15:35
And we're gonna create the handlebar for it.
1:15:36
So we're gonna say it's gets a standard page list header at the top of it.
1:15:41
But then, you know, for the first item, so we'll say this is where we're gonna use some of these helpers that we've created that for the first item in that array.
1:15:52
We're gonna want to set a larger image size and render the promo.
1:15:56
for all the rest of the items, if the index is greater than zero, we're gonna just render a normal promo.
1:16:03
And in our case, a normal promo, the only difference here just has a smaller image that it uses.
1:16:09
because the first item, we're gonna have a bigger first item than the rest of the items.
1:16:14
So we create the handle bar, we create the JSON.
1:16:18
And then, so now the next step is to update the configuration file for the page for the list to have a new style show up in the C MS so that the editors can choose.
1:16:32
So we have this page list config Json.
1:16:35
And actually I'll just view this whole file so you can kind of see the whole file.
1:16:39
And here is where we specify all the lists, we have a through whatever.
1:16:43
But we've got m down here.
1:16:46
And this is where we created the standard list M.
1:16:50
And then with the only two front end options we gave it are a background color and the ability to set inverse colors.
1:16:56
The, that's the only options, you know, we decided for this module that, that we want to give to the editors.
1:17:03
But when we place this in this page list, config file, this this file now is available for editors to choose as a list style for for this list.
1:17:19
So once we've got those two steps, the next step is let's add some CS s for this thing.
1:17:26
So we created a page list, Standard M dot Less file.
1:17:30
We made sure to import it into our All dot Less and then we just gave it some very light styling.
1:17:36
We just do a little grid on the sucker.
1:17:38
We gave it a border.
1:17:41
And then if you're on a bigger break point, we either split this up into two columns or we split up into four columns.
1:17:49
So very, very straightforward.
1:17:51
And then, yeah, if you're the first item, then we span all the columns because we want the first item to be bigger.
1:17:57
So some very basic CS s to make sure that it's compiled.
1:18:03
And then the next the last step here is that we have we want to include it into that navigation file so that it's viewable in our local style guide.
1:18:17
So when this now that the style guide is running, we can now see here there is now a standard list M in our list on the NAV.
1:18:28
And as we talked about this has a just to make it a little easier.
1:18:34
So you can view these, it with, with this navigation or you can view these without this navigation.
1:18:42
So you can deal with things like responsive sizing and check, you know, check just this module in your browser without having the rest of this site around it.
1:18:51
So you can see this is like mirrors kind of what we talked about where we have the first one in a mobile break point.
1:18:58
Obviously, that's the, they're all the same.
1:19:00
But then when you get to a bigger break point, it's got a two double behind it.
1:19:04
And once you make it to a big old, big old break point, you get a four.
1:19:08
So you can verify that this is working well.
1:19:11
It's got all your styles.
1:19:13
I'm locally and I'm working in my HTML cs S javascript and I can make all of these changes.
1:19:18
And like this is like, you know, an example of like, hey, we might want to update some more styling, we might want to say, you know, for the rest of the promos here, you know, they, they're gonna have large text but these promos should have a smaller piece of text.
1:19:37
So I'll have, I'll add some extra CS s that say if you're not the first child, then I want a title six which is a smaller title than title five.
1:19:49
And again, these are the kind of changes as if I am.
1:19:53
Look if I am in my ID E I can go into my code directly and this is where I can make my oops, sorry, this is we're gonna go to styles standard M and this is where I can work with my CS S directly.
1:20:15
So I can say like if I take, you know, this is I'll just say that that gets, and then you see how the text got bigger right here.
1:20:24
And I'm like, I'm looking at this, you know, the designers wanted to smaller text here.
1:20:29
So that's where I'll put that code in.
1:20:31
And then you can see the result of my CS S automatically.
1:20:36
This is also where again, I can either change the CS S here or for example, I can say, and I can simulate what an editor is doing.
1:20:50
Because in this page list, configuration file for page list, M I allowed the editors to change the background color of this module or to inverse the color.
1:21:00
So I can simulate what the editors are doing by filling out those field fields here.
1:21:09
And I can change the background color of this module.
1:21:13
So this is it, this is simulating the editor changing the background color to black.
1:21:19
And then they'll probably at the same time hit inverse colors, hit the check box there.
1:21:27
And that's a bull in and I know that's a bullion because in these in this field configuration file, I created this inverse color which is a bully and field a type that it adds into the C MS that allows them to, to check that check box.
1:21:43
But then I can see that say that first and then, now I can see the fact that the colors are versed because this is again simulating the editor, making these editorial choices that I can create examples of these and check all this locally super fast.
1:22:02
So I can do all of my local development to, to, to be able to work the front end super fast, but then still have confidence that when I upload this stuff to the actual C MS that all of this is gonna work the same way it works on my local.
1:22:19
And that's not to say that we get, we get out of the, get out of like Q A as friend and developers.
1:22:24
But when you're done with your pull request and you're done with your code, you should still deploy it to a Q A environment and just check the actually work.
1:22:35
But you are pretty dang sure that it's going to be because you got to check it in that local style guide.
1:22:43
So this is all, all I've got in terms of the front end training.
1:22:47
So, thanks for attending.
1:22:51
Thanks for listening.
1:22:52
If you guys have any questions, feel free to draw into the the questions panel, I see there's one here.
1:23:03
So I'll go over that in a second.
1:23:05
And then, like I said, Liz is going to be sending out this presentation a little recording of this as well as links to the training rep out.
1:23:17
And there's links throughout this presentation to the training repo as well where it's got the examples of what I talked about.
1:23:25
So if you guys have any questions now, like I said, please drop them in into the questions panel in the webinar.
1:23:32
And then also if you come up with some questions or have something later, you know, you can respond, you can respond to Liz's note and we can figure out a way to, to answer them as well.
1:23:46
So, hang on a second, let me get trying to view this whole question.
1:24:05
So if there's a question about, is there a mapping documentation on what of the allowable keys are in the JSON for instance, like include template wrapper or repeat.
1:24:19
And yeah, it's true that most of them are self explanatory.
1:24:22
But it, it's kind of difficult to know when first learning what the options really are.
1:24:29
We should have that we've got this Brightspot sort of academy where we've got some documentation on this.
1:24:37
But I will make a note on this one to kind of actually just create some CRE create some if we don't have any.
1:24:45
But yeah, I think we try to do these as self-explanatory as possible.
1:24:53
But good call on the fact that it might be difficult to kind of know what those what those specific keys are.
1:25:01
So if I if we don't have it, I'll, we'll definitely, we'll, we'll definitely add that.
1:25:11
There, there's another question about the using the query string to pull down a local copy of a given page.
1:25:19
So, I definitely, this is in our documentation portal, but it's underscore render equals style guide.
1:25:29
That's the, the query string directive that pulls down the JSON view of what that entire page is, which includes you know, all of that root json as well as any any modules that are in that are there as well.
1:25:50
So basically, this is the JSON representation of the entire page.
1:25:57
And then there's one last question from Peter about there's we've got encountered some issues where things work in the style guide, but not on the cloud I think, if you have something like that, we should probably kind of talk about, if you wanna sort of kind of contact Liz and get some more sort of concrete examples of that.
1:26:22
you know, in general, that should not happen.
1:26:25
I mean, I've definitely seen a few instances sort of in my history here.
1:26:29
where if we've created some javascript specific helpers, for example, they, you know, the, the javascript language that's the processor that runs inside of java to sort of process the handle bars could sometimes be different.
1:26:45
But really this would be if, if there is something that that's working in the local style guide but not working on the cloud, I feel that would be a pretty solid edge case.
1:26:56
That's not something we commonly see.
1:26:59
So Peter, if you definitely have that contact Liz or you know, whoever else you're working with a Brightspot, let's try to kind of escalate that and kind of figure out what the particular problem could be because you know, we sort of base everything as a front end team off the fact that stuff in our local style guide should be the same as working in the cloud.
1:27:24
I think one potential common thing and maybe that's what you're saying is that and in general, everything in the Brightspot in this Jason is an array.
1:27:39
So even if you have one item.
1:27:42
So for example, here, this is a good example where the below object sorry, the below key is an array even though it's one item.
1:27:56
So there are times if you want to interact specifically in your handle bar with a particular item, you can't if you're working just with the below and then trying to find a specific key of its first item, that could be a little bit of a gotcha where locally in your style guide, you might have made a mistake and done something like this and skipped the array and made it an object and then something like could work locally.
1:28:36
And that's actually kind of a problem because it'll actually be an array.
1:28:41
So you can't really interact with it.
1:28:44
You have to then interact.
1:28:46
The this template has to deal with its own things because it's just the first item in an array and it is actually not owned by the below key.
1:28:56
So something like that could potentially be what you're seeing.
1:28:59
And that's kind of a gotcha in the sense that you sort of have to remember that in Brightspot.
1:29:05
Basically most most every Jason key is an array.
1:29:10
So everything's in array is a good concept to follow.
1:29:15
But anyways, please follow up with either sort of your who you, whoever you're working with or Liz and we can figure out how to get, get into that.
1:29:25
But anyways, again, that's all I have.
1:29:28
Thank you guys for attending the, the front end training.
1:29:32
And like I said, Liz will be sending out this presentation as well as any sort of kind of follow ups via email.
1:29:41
So, thanks everyone for your time.
1:29:46
Thanks Tom.