Brightspot front-end training webinar

Transcript

0:02

Welcome to the bright spot front end training.

0:06

What we're gonna do today is sort of go over how Front end works with Bright Spot here.

0:14

We've got just some quick overviews of the front end stack.

0:18

What we talk about when we talk about Front end, We're gonna get into a little bit about the roots style guide in the view system, style guide application.

0:30

And then that's kind of what we use for local development.

0:33

We'll talk about the front end bundle which is sort of our collection of front end code as it gets compiled and goes out to get hosted to serve the site.

0:44

And then we'll go over a little bit about each of the sort of languages in our stack that we deal with the most with handlebars for html and translating and our Templating language javascript, which is we use mostly for interactivity, at least in the out of the box bundle that comes with Bright Spot.

1:05

Talk a little bit about styling about less CS S and sort of how we do how we do that.

1:12

And then go over how we've got a lot of JSON in the front end bundle both for using JSON for examples of content and processing the site as well as we're using JSON for a lot of the configuration of the bundle itself and the style guide application.

1:33

So we'll go over through that and then in the end, we'll have a quick sort of code example.

1:38

with a quick little couple of like how tos of creating a new module or creating a style or an option of a of a module as well.

1:51

So, yeah, to get started, a little kind of sort of high level review.

1:57

So front and development here, it's kind of everything you'd think of as front and development in terms of, you know, working on html, working on templating cs S or javascript.

2:09

But also with bright spot, there are some additional controls that let front ends create views and sort of drive what data we need to show on the website.

2:25

And also we've got the ability to incorporate publishing features in bright spot.

2:31

We call those front end fields because the front end devs usually make them.

2:37

but that is a pretty powerful the thing that we have where it lets friend and developers add stylistic fields into bright spot that let editors choose things such as colors or background colors or iconography or other things that are, that are visual and have to do with the front end rather than the, the model data that they have to deal with.

3:03

And we'll go a little bit later into how, how that works and how we use that a lot.

3:09

So for our, for our friend stack, we've got Jason that we use for configuration for the views which talk about as well as for the style guide application for all of the examples that we have been there.

3:26

for html templating language, we use handlebars because all the like basic, all the data and everything that bright spot stores is JSON in the end.

3:35

So we use handlebars to transform that out to html.

3:39

We use L for our CS S preprocessor.

3:41

Now, there's no like hard coded reason to use less versus SAS or just plain CS S or really whatever you want here.

3:49

It's just what a lot of us were familiar with and that's what we've got out of the box.

3:55

All of our javascript is coded using ES six syntax and then we be able to transpire that to whatever we need to.

4:04

we use web pack for a module bundler and to sort of create chunks and whatever sort of optimization pattern you might need for your particular site and, and users yarn to deal with sort of the workflow.

4:21

And then we've used an app that we call the style guide to run the local style guide application and to let us develop quickly locally.

4:33

And we'll get into that also how that works.

4:38

So we're gonna start off by talking about the root style guide and this was sort of mentioned yesterday and talked about in the back end training.

4:46

But we use this the this root style guide to it's sort of the glue between the back end and the front end.

4:55

It's called the root style guide because it usually originally lives in the root.

4:59

But we've kind of relocated to the everything and that's front to the front end folder.

5:03

So, that's where it lives there.

5:06

What this root style guide does is it specifies the views which are a collection of fields and these fields are data that needs to be displayed on the site.

5:19

Each view requires a JSON file and a handlebar file, the handlebar file ends up being empty in that root style guide, but it's a renderer hook to that the back end uses and the JSON file creates the, I'm sorry, the, the data on file has all of the fields that you need to display that particular view.

5:45

And then the view E is automatically generated upon build time.

5:50

And this view results in a java interface that the back end need to implement.

5:55

what, what that means is basically the the back get told that hey, I need a certain fields of data that are in this view and then they have to implement those fields.

6:07

So we create that JSON schema and those fields as we as front end developers know what that's the data we need to show on the site.

6:18

And then the back end devs deal with the actual data modeling, they create the modules or content inside the C MS.

6:27

And then they create the view models that actually place that data on our contract is that JSON file is that's the view that's the data we need.

6:38

And then the back end of know that data they need to get to us.

6:43

And then how they do that is really kind of up to the business for that particular use case that module or that content type.

6:51

Most of the time that data comes from the C MS that data could come from some back end to backend api communication that it could be whatever.

7:02

So like normally the back end training is the the day after the front end.

7:07

So I got in here, you will learn about that tomorrow, but you sort of that we talked about that yesterday and really this, this is kind of a lot of times how we work in the sense that we can work independently where as long as we agree on this view, the front end knows what to show the back end knows the data they need to give us.

7:32

And we, as the front ends don't really care about how that, how we, how that data comes to be.

7:38

We just know that if we create an article page view.

7:43

And that article view has a headline, we just know that the headline is gonna end up being a string because we put, put a headline string into the into the JSON view.

7:55

And then we don't care whether the editor has to type that into the C MS, whether that's automatically provided from some feed that the back end I headline and the design has asked us to put a headline at the top of the article page.

8:13

So we can do that using handle bars to create the html and some CS S to show that.

8:19

So we can kind of, it's cool because we can work independently from the back end.

8:24

Because again, like they can deal deal with the modeling, we can deal with showing this kind of stuff.

8:30

And then that view is that contract that we say, hey back in, we need an article page headline and that goes in the article page view.

8:42

So the way that we develop this and the way that we kind of work front end des is we've got the style, a style guide application as we call it.

8:53

It's our node Js app.

8:55

And it runs locally and it processes the example json view files via our actual handlebar renders that we write.

9:06

And this simulates what's happening with C MS data entry and rendering on the web.

9:11

This uses the DEV environment of setting and web pack to compile our javascript and CS S and it uses the same exact code and build systems that the, that the real site is going to use.

9:25

But it allows us to work locally and then see our work instantly.

9:29

And because it is the same handlebars, it is the same cs S and javascript and we've got trust that the same code will work correctly once it's deployed.

9:38

So again, these we can create while we create this json view in the root style guy and that's the that contract, we sort of create examples of those JSON files in our bundle.

9:53

And then, so we say that, for example, for an article, we can put a headline in there, we can put some words in that headline and then using the style guide application that application runs and it actually processes that JSON using the same exact handle bar that the real site will and it again simulates the C MS runs locally, runs super fast.

10:18

So it allows us to basically do all of our work locally without having to, for example, run the build and push that build into a local version of running bright spot or uploading it up to a Q A environment or whatnot.

10:34

It allows us to, to work local and work super fast.

10:37

So this is primarily where we as front end devs.

10:42

this is primarily what we work with and what we work in.

10:46

when we developed the, the bundles locally.

10:50

So talking about the, the front end bundles, So we originally call this thing of a theme.

10:58

But the bundle is really the front end of the site.

11:02

The kind of calling it like theme has a lot of like connotations built into it.

11:07

So we figured bundle is a little bit more of a real world name for this and this is what we primarily work with is front end devs.

11:15

The bundle has all of the handlebars, all the javascript CS S as well as any like static or SVG assets that we might not want editors to have to control in the C MS, but that we might want just locally hard code in the bundle.

11:33

So maybe it's an SVG for a menu icon or something like that or like a lot of times, for example, we, we'd use scgs for site logos, but maybe we want a hard code one or something like that.

11:46

I don't even, I don't, I don't know, but whatever that, that are hard code assets facility that you don't want in the C MS, you could put those in the bundle as well as all of the JSON for all the view examples because that stuff can show up on the Q A environment so it can get looked at and all the JSON for the configuration because this bundle ends up interacting with the C MS in the sense that this has all the configuration files for those publishing front end fields that might show up in bright spot.

12:21

And it also has configure so those configuration files, all of that is in the bundle so that it, it'll interact with bright spot and actually add those fields into the publishing interface.

12:36

So we'll go through and talk about each of the bits of tech as far as like handlebar, Java scripts and have a few slides to dive slightly deeper into each one of these.

12:52

And then one of the, I forgot to mention this in the beginning, but there's a Q and A section in Zoom.

12:59

And if you guys have any questions about as I'm going over something, Please ask them there if they're like relevant to a particular slide that I'm on, I, I'll just like jump in and answer them.

13:10

And if they're a little bit more broad questions, I'll, I'll go into them at the, at the very end if we have any.

13:18

So talking about the kind of kind of three major pieces I will start with handlebars.

13:24

So that's really how we render html.

13:27

It's our templating language that we like because it, while it does, it's got a pretty good strong separation between template styles and javascript.

13:37

So it sort of lets us create it, it, it's, it doesn't have to put all your, you know, you don't have to use your javascript for rendering.

13:46

You can use this, especially because everything is in Json and Bright spot, it's logic less, but we found it to be a little bit too logic less in the sense that we've created a set of helpers that assist in composing of templates.

14:02

We've created some comparison helpers, some logical and math helpers.

14:07

And then if you need to do anything super complex in the front end, we, you can create your own helpers via javascript.

14:15

We've got some documentation around all the helpers that are in there.

14:19

I found the easiest way to access.

14:21

This is if you just Google for Bright Spot helpers, this page comes up and, and also this presentation well, is, is up online and, and so will this whole webinar so you can, you'll be able to click on these links also.

14:35

But again, if you Google Bright Spot helpers, this kind of comes up and then this, this describes all it is.

14:41

I'll go into a few of them here though and kind of call them out because we use them a lot and they're super helpful.

14:49

So we use equal, greater than less than and, or, or these comparison helpers are not in handlebars, but they're great for moving through item arrays with some logic.

15:01

A lot of times, you know, we found we like, I don't know, we might want to render the first item a little bit differently.

15:08

So we can do an equal of on an index if you're or things like that.

15:14

What we usually don't want to do is do comparison helpers to things that are like strings or whatnot because that can get pretty janky sometimes if you do that.

15:24

So really what we love for these is to move through item arrays.

15:30

We've got in, in bright spot every everything it has a template and there is a lot of parent and child relationships with templates.

15:41

And then we found sometimes that the Children may need some more additional data from the parents.

15:49

and passing that data through Children templates can be difficult.

15:54

So we've created a setter and getter system with some helpers that let you create essentially, we could call them global variables that can get set on parents.

16:06

And those are things that could get set, for example, at a very high level on a page template.

16:15

And then any child template that's rendered on that page has access to that variable.

16:20

So it could be something as dramatic as like a variable that could decide how a certain module renders itself or something as small as like an image size.

16:34

And I'll get into image sizing here in a minute.

16:37

But we use set and get a lot for, for this kind of stuff.

16:43

We've created an include helper that literally includes another template within a template and passes it the current context, we use this literally everywhere and this is something for template use.

16:58

And we'll get into some specific examples to show that.

17:02

But for example, we have a single helper that we've created to render an image or render a link.

17:12

So we don't have to do the same a a tr everywhere with alt or like image with alt tags and sizing and things like that.

17:21

So we created this helper where you can just use includes to support a lot of cut re reuse.

17:29

And then we have this render helper, which is this contextual rendering concept.

17:35

It sort of got superseded a little bit with this include, but it's still used in places.

17:40

And it's a powerful concept that allows us to render a specific style of a template and sort of pre choose that for the editors.

17:52

So for example, we might have a particular we, we call it the promo module, but it's a promotional module.

18:01

It has like a image, a text and a description and a link.

18:05

And it's for example, like some people call it a Hero module or or whatnot.

18:09

And there's a number of different styles, visual representations of what that could look like when we could have an image above some text.

18:17

So where it could have an image overlaid of some text.

18:21

And then we use this kind of render to sort of pre choose a version of that for the editors.

18:28

but then they can go in and override.

18:30

So for example, if you know in the, the f in the body of an like a of a section page or something like that, most of the time we want the editors to, to have a overlaid text on top of an image, we could sort of say that whenever you drop one of these modules, it automatically will sort of render like this unless an editor chooses to override it, which it's a tool just to make editing a little easier for editors.

18:59

And we have this also at helper that we use a lot for image sizing.

19:04

And it's the resize helper and this is a directive to receive a specifically sized image from DEMS which is our image sizing system.

19:14

And this is used a lot with a set and get helper to allow for code reuse and contextual image sizing.

19:22

So I'll show a couple examples of that as it's this is super useful.

19:30

So we've got a an image and an image tag, which is something that we use either via that include helper in places.

19:43

And this uses that resize helper to resize the image that it gets to a specific size.

19:54

And it uses the get helper to get the image size variable that might exist.

20:00

So this lets really everyone use this helper.

20:06

Oh I'm sorry, you, we use this handlebar file via the include H but set their own image size that they might need.

20:13

So for example, the recipe module wants a medium four by three image And it can set the image size variable to that.

20:26

And then they can render the image and which uses the image renderer.

20:33

And again, that code gets this is reused everywhere.

20:37

This image tag is coded once in a code base here.

20:40

And this but this will actually fetch a four by three image which is specified in an image configured file, which I'll talk about in a little bit later.

20:51

And it'll render that if you skip this image size set declaration, it would fall back to a large 16 by nine, which is sort of like a fallback default images just in case if you miss this image size in your modules.

21:07

So whether this is an article lead or a carousel or whatever, all of these guys can reuse this image tag helper and set their own image sizes to create to promote lots of code reuse and so promote some nice pat nice cleaning patterns throughout the code base.

21:31

So these are again just a few of the helpers, but I just wanted to call out some of the more wildly used ones.

21:40

But again, if you Google for bright spot helpers, you see them all and a description of how they work.

21:47

And again, there is a these helpers get run through actually javascript and his helpers at Js file that's in the it's in the training bundle that you can see that training bundle is publicly accessible.

22:04

And in there, you can see some examples of some like custom helpers.

22:08

And if you need to do something, you know, super custom, you can write it in javascript in there and actually have a custom helper written too if you need to.

22:20

so to get into next up javascript a lot of times or not, a lot of the times, but in our bundle that's out of the box.

22:30

We use javascript really for interactivity.

22:37

We use ex six written javascript.

22:39

It's a mixture of classes and custom elements.

22:42

Again, we use bubble to trans ple it into using browser list into whatever browsers we need to support and deal with poly fills and whatnot for other browsers that are, that are old.

22:57

And then we use we web pack to package our javascript into a combined javascript that can be loaded on every page as well as chunks.

23:07

that can either be dynamically loaded, you can manually load them on other page types, that sort of pattern is really up to you and your site.

23:18

And we don't try like we just offer up an out of the box sort of example and what we, you know what, what we chose for that, but you can take it's it's web pack.

23:29

So there's lots of plugins, lots of options and lots of availability to optimize that or deal with that however, you will.

23:39

And then, so we mostly use custom elements to bind javascript to the Dom.

23:45

And then we find that for most content driven sort of, I use it in air quotes really but static sites.

23:52

We don't really need a big javascript framework to just weigh down the site and sit there and, and there are no state or views to handle in sites like that.

24:03

This allows us to use javascript to make the site more interactive and enhance the html versus using it for the rendering since we're using handlebars to deal with the rendering.

24:17

You know, an example of that is something like our carousel javascript, that is a custom element.

24:26

And it's got a connect the call back.

24:29

In this particular example, we're using Flicky to deal with the actual carousel and sort of offload the workload of the carousel itself.

24:39

And you can see where this custom element is actually an async.

24:44

custom element.

24:45

It uses the weight syntax to dynamically look Flicky web pack will take this and chunk out the potentially heavy Flicky third party code into its own separate bundles.

24:59

And then just take this lightweight custom element that deals with essentially setting the carousel and dealing with some arrow repositioning if you because, you know, like for, for our bundle here, the arrows are, you know, halfway down the the slide.

25:16

And we might need to reposition them if you change your change your browser and add dots or whatnot to the carousel.

25:23

So in this case, this little bit of lightweight custom element code is compiled into the all dot Js and comes to every page.

25:34

And if a page happens to have this custom element, then it'll go off and dynamically load the third party Flicky code on that particular page.

25:44

So this is the kind of pattern that we use for a lot of our interactive javascript.

25:49

And again, we sort of find that we don't need a full javascript framework to run on top to deal with this kind of stuff for us.

26:00

That's not to say that we don't use these type of frameworks on sites all the time.

26:05

And especially when necessary.

26:07

But we find that a lot of times again, the site is content driven.

26:13

And then only a portion of the site is an application.

26:15

So in those cases, what we've for example, what I'm gonna use is like a scoring leader board on a sports site.

26:24

For example, we find that that scoring leader board is a very interactive application that has state it's got its own sort of views that it needs to deal with and it needs to dynamically sit there and hit a graph QL end point to get the scoring data and render itself.

26:44

So then we will, we can dynamically load, react for example, on that page, after that custom element loads and then that react that whole entire leaderboard can be essentially it's call it a leaderboard module on a page.

27:04

And that module is very interactive, very dynamic.

27:06

It sits then hits a graph QL endpoint, it does its own rendering.

27:12

But the page outside of it, including the editorially published modules as well as maybe in a side rail and the header and footer and all that stuff that's still gonna be statically rendered through handlebars and through, you know, custom elements and CS S.

27:28

So that's what we do most of the time.

27:32

But again, this is nothing in right spot is you know, sort of hard coded or pushed or has to be done a certain way.

27:43

So sort of this whole, this pattern that we follow could easily be switched to where, you know, the bundle, for example, maybe only deals with a static header and footer and then the whole content could come from javascript applications that are that, that use graph QL.

28:01

There's nothing preventing a site from doing that.

28:04

If it, if it needs to.

28:08

So now to talk a little bit about styling and CS S, we've used less as a CS S preprocessor again, that's sort of the out of box a bundle and there's nothing preventing someone from you know, converting to SAS or just, you know, starting over, if there, especially if it's a custom design where it might not use the same HTML and CS S that we do in our out of the box bundle, you'd more than likely be deleting all the CS S and styles anyway.

28:38

So the only thing that makes less work is the fact that we use the less plug in for web pack to process less.

28:45

You could use any CS S preprocessors that you'd like.

28:49

But out of the box bundle, we use the BEM style syntax for class and element naming versus using a full object oriented CS S framework such as like Tailwind or something like that.

29:05

We, we found that for us that CS S changes and bug fixes are a little bit less likely to create regression issues with something like the BEM style syntax.

29:17

And we found that it allows multiple developers to work together a little bit more easily as you don't have this like waterfall style thing where some developers are working on the OO CS S framework and then some are and just implementing it and then sort of waiting and can't make changes to CS S because it might impact lots of other stuff down the line.

29:40

So we in the out of the box bundle, we use descriptive names for modules and components and then use that sort of ben style syntax to name their elements.

29:52

We do use a little bit of object oriented CS S but most of the time we use less to abstract certain styles.

29:59

It allows us to use less extended mix ins sort of depending on the use case.

30:05

So one example for that is where we use, we've got AAA page list in our world.

30:16

A list is a very generic type of module that can have many different styles or visual representations.

30:24

So list is just a list of promotional elements.

30:27

So whether that is a list of big visually big promos at the top of the page that might swipe across or contain a little carousel of four promos or it's a module that contains, you know, 10 10 little grids or 12 grids of of promos or something like that.

30:49

Those are just different visual representations of the same list content type.

30:54

So we created this like object oriented style list, putter and items and sort of some like next load more type navigation that uses the page list, sort of naming scheme and then each individual version of that list.

31:13

We've got for example, page list that standard A and what as far as the naming you'll notice in the in out of the box bundle and training bundle.

31:22

We got, we don't have a very descriptive names for these just because we just call them like a through whatever.

31:30

And then there are in the configuration files, there's the ability to do to give display names where we could give editors a little bit more descriptive names for these things.

31:40

But we've found in the past that naming things is actually way more difficult than we thought because like everybody has an opinion on how something is named.

31:49

So we just went with the generic A through Z naming of lists.

31:53

And then again, we could give, if the editor team, editorial team wants a certain visual name, we can give that to him via the display name.

32:02

But again, we like page with standard A has that will have a html name with class that way.

32:10

And then, we found that this sort of pattern allows us to create some very like broad level styles for the generic sort of page list, which is sort of the parent and then each individual list can have its own styles.

32:29

And this way, as a developer, you sort of know a little bit more what you're working on when you're working on it.

32:35

And then you can also sort of see your CS S bugs and see what you're working on.

32:41

And if you get asked to make a change to the standard list, a spacing, when you do that here, you'll know a little bit more exactly what you're working on.

32:51

And you'll be able to make that change with CS S rather than like utility classes.

32:56

And then that way, it's a little bit more potentially targeted to what you're doing and you won't impact other developers or cause regression issues.

33:06

So that's why we went that way.

33:09

We use four variables.

33:13

We decided to use CS S bars and less variables.

33:20

kind of intertwined where we use CS S BARS to set values, whether they're set in a CS S or in line html.

33:28

And CS S bars allow us to create a nice pattern where we can set CS S variables through C MS editorial fields to allow editors to customize whether it's the modules or the whole site.

33:42

We use less for variables for places where variables are helpful for developers.

33:48

But editorial overrides aren't necessary.

33:51

So to show what I mean by this is for example, for something as global as colors, we've created a we created a set of editorial fields using configuration files that lets developers.

34:10

I'm sorry, editor, editors control the colors of the site.

34:14

So the editors get a set of editorial fields, we as front end developers created where they can create the primary color, the text color, the site background or a border color, the generic bo border color.

34:28

And the editors can control all of these colors using those values that come from the editors.

34:34

We set, you know, root based CS S variables for ourselves.

34:39

And then we use these variables in directly in our CS S so that you know, for the page header background, we use the color header background CS S BAR.

34:53

So this allows us to create a pattern where the editors actually have control of the background header color.

35:03

And then we create a fallback for ourselves That if the editor does not set that color in the, the theme or a theme version of that themed version of that color for themselves, we fall back to a white background header color for ourselves.

35:25

So we've kind of created this sort of pattern and that's CS S variables allow us that sort of pattern because you can set those CS S bars at the root.

35:35

And then later on, you can use them in all of your CS S.

35:39

So that's, it's pretty great.

35:40

We use that a lot for whether that is used for something like this where we set in the root.

35:46

But then a lot of times we use that on modular level where if a module has a certain background color, we could also give the editor the control to create a background color on a particular module.

36:00

And then we can create an in line tag at that top html wrapper of that module to, to, for example, reset, maybe a variable or for example, you could reset if a module is gonna have a certain text color, we can set a primary text color in CS S for the, for the site and for certain elements.

36:25

And then for a particular module, we could give an editor the ability to override that a text color for that module with something else.

36:36

And then we can do something as simple as resetting this variable with an in line style tag.

36:42

And then all of those Children will get that, that same CS S will just be reused, but the CS S variable will change creating a nice pretty pattern.

36:51

So we use that a lot.

36:54

So now, you know, let's get into a little bit into JSON.

37:01

And we've got that sort of everywhere throughout the bundle.

37:06

We use this for the view examples that I talked about a little bit as well as configuration of the style guide application itself as well as configuration of how the bundle is gonna interact with bright spot.

37:23

So these JSON example files that we used, they're used in the front end bundle to simulate how the C MS was going to fill out the views.

37:35

This allows us to create ourselves local examples of content type as well as like full entire pages locally.

37:44

So when we run this local style guide, we can then see this JSON transformed using our real handlebars, JJ S and CS s and, and show that locally.

37:58

So what I mean by that is you can see in the training bundle no A, we've got a article page.

38:09

And then if you go into the root style guide, you can see the data, then the contract that we set up with the back end and on what an article page has in terms of content.

38:23

And then in terms of fields and then in the bundle itself, we're gonna create an example file for an article page.

38:34

And then when we run the style guide application, it will render an article page using the same article page H BS that it would on the live site using all of this sort of test data that we created for that we input here for ourselves.

38:51

So we're essentially sort of simulating the C MS by creating these files.

38:58

And again, sort of, instead of having to run the C MS application like instead of running Bright spot locally or running bright spot on some Q A server working with our code, having to then fully bundle it.

39:14

We can instead do this run the style guide app and see our changes instantly.

39:21

So as well as you can make these example files locally manually.

39:29

But also since every page is every page in bright spot is just JSON.

39:42

You can use a underscore renderer directive and the queer string.

39:52

And this will show you the Jong that is behind a particular page and you can copy and paste this stuff into your style guide.

40:05

If you want to use examples that have been you know, that are from a pre existing site or something like that.

40:14

Or if you have your editors that created some, you could you know, use this because it's got the promo, it's got the description in here and it's got an image that's been uploaded to the C MS with a path on CD N.

40:28

So you could get a title so you could use this.

40:31

But what we like to do a lot of times is create these examples manually.

40:37

because we've got some word generation, word generation and data generation helpers that are created that allow us to create some data that's like basically fake la and s some style data that can stress test our design and our and our html a little bit.

40:58

So for example, in this article page, you'll see that like we use a generic date here and then the headline and sub headline.

41:05

we use the words helper And then that drops out between five and 15 random words for the headline.

41:15

So this, it lets us create some laum s some style examples in our local style guide.

41:22

And that will again, sort of stress test because every time you refresh your page, you're gonna get a headline between five and 15 words.

41:30

So you could put 50 words in here.

41:33

And then you could see that maybe sometimes like here's what my page would look over the five and I'll refresh and see what it looks like with 50.

41:40

So this way, it's a little bit versus using some hard coded words and then, you know, hey, five words work great in this design.

41:49

But if I put 50 it breaks the design, This will kind of let you pull out these like the these edge cases using these sort of data generators.

42:02

So, also if wi with these data, data generators, and the local style guide, if you don't specify the actual source of an image, we will generate an image for you a gene image with a, with a placeholder for you with the exact size that the resize helper would normally get from the C MS.

42:31

So it lets you get sort of realistic also image sizing.

42:35

So all that is built into the style guide application.

42:41

So we've also got Jason config files throughout the the style guide, I'm sorry, throughout the bundle.

42:52

And these are the config files which impact the way that the bundle interacts with bright spot as well as the Style Guide app.

43:01

So we're gonna talk a little bit about some of the config options here.

43:05

But these configuration file contains all the image size options.

43:10

All these additional fields that the front end can add into the C MS.

43:15

Because then once the bundle is pushed out into the C MS, that's how you know the editorial interface can run in fields in from the bundle.

43:26

It has all the style guide, the style variations of the content types so that the, that those are given to editors as options to choose from.

43:35

And then they config files are defined at the root of the style guide.

43:41

or in subdirectories, we try to encourage people to sort of place them in the subdirectories where they where they make sense.

43:50

And really run time, all of these configuration files are actually combined into one genre config file.

43:57

We orig originally had this as just one giant config file.

44:02

But it got to be a, just a giant mess of merge conflicts.

44:05

So that's why we split it up into just like we call I just kind of call it stardoc config dot JSON and they're, they're all over the the bundle.

44:13

But again, they just get kind of compiled into one big config.

44:18

So one specific call out is the JSON configuration for image sizing.

44:25

These images image sizes are defined in this configuration file.

44:31

And then once defined, they can be used with the resize helper to request those images.

44:37

So in the training bundle, for example, we've got this image sizes, config dot JSON which is in the root of the base of the style guide folder in the bundle.

44:50

And this has all of the image sizes that modules can use and can act, can ask and they have width and height definitions that are then fed over to Dems and Dems will return that size.

45:10

We also have the ability to specify instead of just a, a specific with an height, if you need more of a variable image aspect ratio, We also have the ability to provide something like a maximum height or create something that maybe has a hard coded width but does not have a site height specified and then you'll get a 1440 wide image.

45:40

and then it'll use the aspect ratio of the source image that's been uploaded to create a variable height image.

45:49

So for example, it's an image size like this is very useful.

45:54

And so maybe something like a car like a whole full page modal overlay carousel where you might wanna fix a, a particular height, but you might wanna show portrait or landscape images.

46:07

In those particular iterations we use, you will see this like preview height or preview with.

46:13

And then this value is actually gonna be used by the style guide application because when it's generating that image in the style guide application locally for you, it kind of needs to know an example image to provide for you.

46:28

So it'll provide a 600 by 1440 image here in the root style guide.

46:35

And then another call out for a particular config files is for these front end fields.

46:43

So these are the additional fields that are added to the styles tab in the C MS that allow editors control over certain styles of content types.

46:52

So these fields only persist for this particular front end bundle and they're not part of the content types data.

47:01

And that's a super important call out because these should not be used for data for that content type, but they should be used for additional styling options.

47:13

So we really like to use these things for something like background color or image alignments.

47:19

But really don't want to use these for like text because usually something like text might belong in a modeled field.

47:29

So for example, in a article, you'll have we have a field called article lead style.

47:41

And that has a style type where we have a standard lead or a large lead with a big image or an overlay where the headline is on top of a big old image or maybe a nested lead where it's in the content type.

47:55

And this is a great example of a front end field because it's purely visual, it uses all the same data from the article page, but it has, it allows you to, allows the editor to visually change what an article might look like but not actually add data or something like animate on scroll, like you might wanna animate this module on scroll, yes or no as an editor.

48:23

That's a great front end field because it's got nothing to do with the data, but it's a very visual kind of kind of thing.

48:31

And when you add these fields to particular content types, you add it to that particular modules, config dot JSON in a fields tab I'm sorry in the fields key.

48:46

And this is a great example too where you know, p promo module A is a certain type of a certain look of a page for emotional module.

48:57

And it has a bunch of fields that we add where you can hide the category or you can show the B line or it lets the editors change the text alignment, the background color or inverse the color of the, the, the text in that module.

49:15

And these are all fields that the editors can control for this particular iteration of this module.

49:22

And these fields they can make the these fields are independent of the content.

49:29

And they only persist for the in this instance of this module in this bundle.

49:36

So that's again, super important that we don't, we don't put like modular data into these fields.

49:44

But it, but use them for visual display.

49:49

And then the last kind of call out here is the JSON configuration for the styles of these content types.

49:59

So this page list or page promo module are perfect examples of that.

50:06

And this is what I was talking about where it's the concept that lets us create many different looks of a content type in the same data schema.

50:14

So something like a page list or page promo module is a content type that is used to assemble lots of pages like a home page.

50:24

So if you go to a just like the like a home page, you know a module like this is this module on this module or oops, sorry, I click on that.

50:40

But like this module is a promo type module where it has an image, it texts a description and a link.

50:47

This kind of module is you know the same exact thing as this guy with some editorial options.

50:54

And these can take many different looks and feels.

50:58

for example, if you had a module here where this text was actually this had a little bit of a background and this was overlaid on top of this.

51:07

It's still the same data schema and it's still the same page promo module.

51:12

But we call it a different style of the page promo module and we create different handlebars for it, different CS S for it and then we put it in this configuration file.

51:26

And then this is what gives the editor the choice to when they create that page promo module and they input that data for it, they get to choose which style of the rendering they choose.

51:40

So in this training bundle, we've got the A B and C iterations of this page promo module.

51:51

And then the editors these examples in here are the examples that we made in that bundle that the style guide application can run and we can check these in our local stuff guide, but also at build time, the sys the build system pulls up these examples, takes little screenshots of them and then gives them to the editor.

52:15

So when they put in page promo, a page promo module on a page, they get a little visual picker that has little screenshots of the examples for them.

52:29

So they can choose which visual display of that module they want to show for that particular instance on that particular page.

52:37

And then they can go in and you know, modify this one further.

52:41

Because for example, I, I don't remember exactly now, like which one A versus B, but I think A is the one that has the image above the text.

52:53

And I think B is the overlays.

52:55

Yeah, the B is the overlay style.

52:59

So for example, this particular one is page promo module A with maybe the default alignment, whereas this one is same exact module, but the editors chose to do the horizon horizontal alignment of image left versus image, right.

53:18

So it can be the same module with the front end field to change the display.

53:24

Or if you didn't want the editors to have to go through that extra step, you could create two different styles of page promo module.

53:35

One that is automatically aligned left and one is automatically aligned right.

53:41

And then the editors get to choose that via screenshot versus having to choose one that had horizontal alignment and then having to choose a drop down to choose left or right.

53:52

So depending on your use case and how many editors, how many modules you've got lots of options to how to arrange these configuration files for different styles as well as different options and fields within each style.

54:12

So having gone through all of this, I wanted to go through a couple of code examples real quick.

54:23

And the two good examples that I have.

54:27

the first one is really kind of creating a whole new content type.

54:33

And then the second one shows making a new style of an existing module that already has an existing content type, but just making a new look and feel of that particular module.

54:49

So for the first code example is creating a whole new front end.

54:53

So, you know, in our out of the box site, we don't have something like recipes or meals or ingredients or whatnot.

55:01

So if we were asked to create a new content type for a recipe page and a recipe module, to kind of start out, we'd have to work with those, the back end team as well as the product team to really determine what the heck a recipe page and a recipe module look like.

55:22

And we, we're usually given a design and then, you know, the the designers create this and then we work with product and back end to sort of to model this out or nothing really model this out.

55:32

But we as friend and developers talk about what the view and what the data that we need.

55:38

So this, we create in that root style guide folder, a recipe page and a recipe module.

55:45

And then this establishes that content between contract between the front end and back end, it's placed in their roots style guide.

55:53

And then once that is done.

55:55

We can then as front end developers go off and work because we have the contract.

56:01

So this is something that, you know, we talked about yesterday in the back end training also.

56:06

But like we create our, you know, recipe folder and we create a recipe article page JSON as well as a recipe module, JSON.

56:16

And these are the fields that a recipe article page is gonna be need to show itself.

56:24

It's a sort of creative work page which takes care of a lot of the other fields such as the fact that it's gonna need a headline and a title and like metadata and all the header and footer and all those, all those kind of fields.

56:41

And then, but aside from that, you know, it's gonna need a lead, it's gonna need an article body itself because there's you're gonna describe and talk about the recipe.

56:53

And then it's gonna have the recipe itself, which is actually gonna be a recipe module.

56:59

And then we're also gonna then create the view for the recipe module.

57:04

And, you know, based on a certain design for what a recipe module might look like, It's gonna have, you know, these fields, it's gonna have a title and image difficulty, prep time, et cetera, et cetera and it's gonna have some ingredients and directions which will just be RT ES that the editors can fill out.

57:24

If you wanted to get like, for example, based on a design, you might have you might create a bunch of steps here or something else like that.

57:33

But, you know, in our case, we don't need to.

57:35

But once we have this recipe module, page and recipe article page, we can then get started on the front end because we can take these JSON files, we can create examples for them in our bundle.

57:52

And then we can start developing on them totally separate from the back end, who's gonna work inside the C MS.

58:01

So, you know, our, our step one for that is to create in this default bundle in the recipe folder.

58:12

We're gonna create an example article page for ourselves as well as an example module for ourselves and what these look like are the article page.

58:28

It's basically AAA an an actual article page.

58:31

So we can just kind of reuse an article page.

58:35

And then the article body is just gonna be a short couple paragraphs that are gonna describe the recipe and the recipe will just be the recipe module.

58:46

And we again use that include syntax.

58:48

So we don't have to copy and paste the whole thing.

58:51

And then the recipe module will use these words helpers to create a generic title.

59:00

We'll use the image to include an image to create some sort of generic image.

59:04

And we'll put in some basic strings for ourselves that we can use in the local style guide.

59:12

When the local style guide is run as well as some this kind of simulates some html coming out of the RT E and the directions are a simulated couple of paragraphs.

59:24

And when we put this in here and run the style guide, and sorry, and then we're gonna do some handlebars on top of that.

59:31

So rest it, we'll just get into the recipe module instead of showing the whole rest of the page.

59:36

But you know, we'll create the, the HTML for it will drop the title, all those fields in there.

59:44

We wanna set a medium four by three image using the image size, getter and setter.

59:50

And then we'll drop in some ingredients and directions using this HTML and then whenever the local style guide application is run, that will run and I've just got it running already here in the terminal.

1:00:07

And then that once that application runs it pulls up, you can pull that up locally.

1:00:21

Sorry, let me switch to the branch that has that and run the style guide look real real quick.

1:00:31

put them here.

1:00:33

So this is the style guide application running here locally.

1:00:40

And then when I've got that, I can then render this recipe page here.

1:00:47

It is running inside the style guide application with like that left hand menu or I can just run this, you can open these up as a new page, so you can run this recipe article page which has the recipe module here.

1:01:04

And these are the examples that I example text that I put in for myself.

1:01:10

And this is using the exact same.

1:01:14

And actually, if I just I'm sorry, let me pull up a little ID E here.

1:01:21

And this right here is using this this is the training repo pulled up.

1:01:27

This is the recipe.

1:01:31

Where are we at recipe page which is including the recipe module, the recipe module has all of this example content and then I can change all of these here instantly.

1:01:51

I can say sorry, here we go.

1:01:55

I can save that and then I can pull all of that up and I can refresh this page and I can see my changes here instantly and that way I can develop, I can change use cases.

1:02:08

But furthermore, with the style guide application running, the when I change the HTML and I make a change to it and I refresh this page, I can instantly see the changes to my html without having to build without having to do anything.

1:02:28

And the local style application is also running Watchers so that when I change something like CS S, So I've got my recipe module here.

1:02:41

And if I make changes to my CS S in, it will automatically it's got a watcher, it compiles it here when I make my changes.

1:02:55

So then I can instantly see my changes locally.

1:02:58

And this is using the same and this is kind of where the local style guide comes in.

1:03:04

And it's really powerful because this is running the same CS S as the bundle will on the live site.

1:03:10

It is using the same exact HTH BS renderer that the live site will.

1:03:16

So I've got confidence that the handlebar and the CS S changes that I'm making here are going to be represented real on the live site.

1:03:26

So I can do the, you know, 100% of my development here locally.

1:03:32

And then I only need to upload, run a local instance of the C MS or push this out to a Q A instance of bright spot just to basically double check and verify that everything is still working properly.

1:03:47

But I've got really great confidence that I can work and do my friend work independently of the back end because while the back end is modeling this recipe module in the back end and actually creating all these fields for the editors, I don't need to wait for the back end to make all these fields because I have that contract, which was that style guide that set all these fields.

1:04:15

So I know that the back end is giving me a difficulty field, that's a string.

1:04:19

And I can confidently use that in my handlebar file, knowing that I will get the difficulty from the back end as a string.

1:04:29

So that's sort of the pattern that we follow for making new content for making a for editing existing content.

1:04:42

Let me switch over to this branch real quick that has this new list style in it.

1:04:49

So, for example, in this particular code example, we've been asked to make a new style of, of a list.

1:05:02

So if I run the style guide application here and I pull up you know, local host, we've got a number of standard.

1:05:13

So a list is style A has a list where the first item is bigger with some smaller B has a grid whereas C or like D has a, it's list items are presented this way.

1:05:29

So these are all the same data type But they have different visual representations.

1:05:36

So this is what we get to ask a lot is hey, we need a different, another visual represented.

1:05:44

Another visual representation of a list added because designing wanted to create a new one.

1:05:50

So when we, when we get asked to do that.

1:05:53

Let me pull up just this pull request that we have against the training repo that has the commits.

1:05:59

So I can just go through each of these commits of how we do that work.

1:06:03

So, you know, to, to start off with that, we'll make a, a new list and, you know, we, we had him up to also we'll make a new list called M here.

1:06:15

And then we'll make a new example of this.

1:06:18

So we'll say that this is standard list M.

1:06:22

It uses the standard list M style template.

1:06:26

But the template key is still list because that's the content type that it is.

1:06:31

And it has an, a separate title but then it gets, you know, nine items which are promo items.

1:06:38

So this kind of is a instance example of what this would look like.

1:06:45

But it's modeled off the page list view that is in the root style guide.

1:06:51

So we create this example for ourselves and then we're gonna want to create the html for ourselves like and then when we create a simple, like, you know, if there's no items because an editor didn't add it, the list won't even render itself.

1:07:03

But it's a standard list M and then it creates a couple of wrapper Ds.

1:07:10

And then it uses, it says that it based on the design, for example, that if you're this is where we use those like helpers that, you know, with the first item.

1:07:22

we're gonna want to set a larger image size and render a standard page promo inside of it.

1:07:30

But otherwise, if the items are, the rest of the items will get some smaller promos, so we can write the html for this particular list in this standard list and handlebar file.

1:07:45

Then on top of that sort of the next step, once we create that html, we're gonna update the configuration file with the style option.

1:07:57

So we already have that page list.

1:07:58

Config Let me just show the full file here and this one has all the lists like a through L right now.

1:08:07

And then what?

1:08:08

We're gonna make a new one here at the bottom and for that new one, it'll use that example that we created as the screenshot in the C MS.

1:08:18

But it also is gonna give the editors a couple extra fields that this is something usually that product or design asks for where it might be a background color or it might let the editors, you know, inverse the colors.

1:08:30

If they add a black background, they're gonna want some white text.

1:08:34

So we create this add this now and now sort of once it's in the configuration file here, it's an official style that the editors can choose when they create the standard list.

1:08:48

and in the in the C MS.

1:08:53

So the next step is, you know, us adding some CS S to this.

1:08:59

It's what we just created some very straightforward standard CS S that's going to just show this thing as a grid.

1:09:08

And, and break points.

1:09:11

You know, we might just show different, you know, like two columns and a medium break 0.4 columns and a larger break point, you know, very straightforward, kind of, kind of simple CS S and for this example, but I need more complicated for you.

1:09:26

And then we're gonna update the style guide to show that new style.

1:09:33

We will have a, we have this navigation config which is what controls this left side of this style guide.

1:09:42

So here, we're gonna add this guy here on the navigation so that it's down here to be looked at and, and Q A and evaluated by and, and checked out by our like, you know, developers just to make sure that this matches the design we've been given.

1:10:05

And then lastly, you know, we can sh I, I'd show here like, you know, making a CS S update.

1:10:15

And how like that is going to that you can say that, you know, maybe for the first not the first promo, I want a smaller title.

1:10:26

than the other promos have.

1:10:29

So the, the CS in the CS S the title text is a little smaller.

1:10:33

But you can, then I've got the style guide running here locally.

1:10:38

So I can see this example.

1:10:43

I can see, you know, all that, the example text that I chose and I can see that this sort of matches the design that I chose where like when you're in a, a smaller breakpoint, it shows them all.

1:10:55

When you move to a medium break point, it shows two columns here.

1:10:59

And if you're in a larger break point, it shows four columns here.

1:11:02

And again, I can, this is all styles and code that I've created and I can mess with here.

1:11:15

And again, I can do this stuff locally.

1:11:21

I can see my changes instantly because when I change the CS S, this goes ahead and changes it instantly in the style guide.

1:11:30

So I don't have to like sit there and upload this to the local C MS.

1:11:34

And then also I can see, I can double check my example, Jason, so that when I look at this page list, standard M example that I created for myself here.

1:11:50

If I want to change this around and like, you know, what will this look like with five page promos in it?

1:11:57

I can change that I can see that and I can see it instantly this also because this is the same json and the same sort of pattern that's in the CM SS if I created front end fields.

1:12:15

So for example, in this page list config file, I in the standard M, I allow the editor to change the background color or inverse the colors.

1:12:27

I can also simulate the editor doing that.

1:12:33

And that now JSON gets fed to this example.

1:12:39

And then this is what this module is gonna look like if the editor chooses a background color red or maybe inverse colors.

1:12:49

Let me double check inverse colors here.

1:12:53

I can then go into the fields.

1:12:56

Config and inverse colors is a boolean here to change primary text color to the primary inverse colors.

1:13:04

So I can inverse.

1:13:05

So it's a boolean so I can set that to true and then that'll set all the colors so I can simulate that the editor here is messing with these settings.

1:13:16

I can simulate the editor messing with these settings and make sure that all of these settings and my handlebar file is reacting to these settings correctly.

1:13:27

So I can do all that locally, I can do all that super fast and I can verify that all my code is running.

1:13:34

So this is again sort of showing this example showing the style guide application running.

1:13:40

And as front end developers, like I said, we don't really have to jump that much into the local C MS instance, except for testing to make sure that all your code is working.

1:13:54

Because instead we've got this local style guide application and all these examples that do all of this for you.

1:14:02

And that's again, pri like to kind of circle back, that's primarily as friend developers, what we work with hair bright spot.

1:14:13

So we've had a, there's a question in the Q and A about something for back end as community develop, developed and bright foot approved items during the back end training yesterday, is their equivalent for front end commonly essentially like commonly needed already made content types or do they usually contain front and back end elements?

1:14:38

So there really isn't anything like that beca and that's for front end and really for front end, every instance of a site is essentially unique on the front end, right?

1:14:51

Because the CS S the styling, the HTML is super different per instance.

1:15:00

So while we have sort of out of the box bundles that get put out, most customers change the heck out of those and those things diverge super far from each other.

1:15:17

So really, yeah, we don't really have concept like a concept like that for front end at all.

1:15:24

And again, that's it.

1:15:27

something also like none of the front end here, none of the html.

1:15:31

None of these patterns, none of the CS S none of the javascript, none of that is prescribed by a bright spot in the sense that it has to be used this way or that the CS has, has to be written this way or the Js.

1:15:47

So for example, I talked a little how we use out of the box bundle.

1:15:52

And in the training bundle, you know, we've got object, we, we don't really use object or the CS S or something like a tail and CS S library with OO CS S class designations for, for things like grids or sizing or, or colors or gaps or whatever.

1:16:12

And that's not to say you can't use that at all.

1:16:14

Like it would be honestly fairly straightforward to re to pull the CS S out of the bundle and then change the html of and pull in some like a tail wind library, change all the html classes around to use that and move to that pattern instead.

1:16:38

So really like we don't, we don't really have that done again.

1:16:44

This is sort of the example in out of the box because we found that sometimes is actually even it is harder to work with than this sort of be favored bem kind of pattern of approach of CS S but customers can do that and you're free to do that.

1:16:59

And so you're free to sort of take the front end and just like move every which way as you need to.

1:17:09

So that's kind of what I've got for the whole front end sort of training and the overview.

1:17:15

And then just to have a little call out at the end of April, there is the Bright spot user conference in Reston.

1:17:27

And then it's got the Hyatt Regency.

1:17:31

And we're gonna have two days of sort of, of, of insights and connections with the bright spot community you in then like during that conference, you can get a glimpse at the product roadmap, hear from analysts and customers on digital experiences and sort of dive a little bit deeper into developer focused topics about A I some of the right API S that are out there.

1:17:56

And there will be some roundtable topics in there.

1:17:59

The agenda as well as registration for the free user conference is on the bright spot website.

1:18:08

So check that out and we hope to see you there.

1:18:12

And thanks so much for attending the front end training.

1:18:17

And as I kind of said earlier, we're gonna have I, I think Jill actually, if you can correct me if I'm wrong, I think there's a questionnaire that goes out.

1:18:27

And then also, there's gonna be the training materials, the link to this webinar as well as this presentation, which has all of the links to the the tr that training repo, which is again, it's a perfect github perfect sense training is out there and that's public and you can take a look at all those and, and load that, run the style gad application locally and all that and run those good examples as well.

1:18:56

Thanks for your time, everyone.