Mazel relies very heavily on its configuration, and as I say that it sounds obvious, and that's true for any project, but especially for Mazel, because it is highly configurable. So the default configuration relies in the config.js. We can see that this is the development config, but this is the default config. And if we look at the actual configuration, we can see that there is this build object that has a templates, where we define the source, which is source/templates, which is where we have been working. So if we needed to change where our templates resided, we would need to change that option. But then there's this destination. We can see that the path is build/local. Now we haven't looked at that folder, but it's right here inside of our project,

there's this destination. We can see that the path is build/local. Now we haven't looked at that folder, but it's right here inside of our project, and we can see that there is digest.html, documentApproval.html, and invoiceApproval.html files. These are the files that Mazel is building and is loading inside of the browser. So what we see here in the browser is that digest.html file. So let's open that up, and we will see the resulting HTML. And here we can see the conditional comment for Outlook. So this MSO is Microsoft Outlook. So Mazel has taken that Outlook element that we used inside of the digest template and translated that into this conditional comment. But Mazel, as I mentioned, is very dependent upon its configuration. And if we wanted to, we could change this Outlook.

translated that into this conditional comment. But Mazel, as I mentioned, is very dependent upon its configuration. And if we wanted to, we could change this Outlook tag, so that instead of Outlook, we could say MSO. So let's make that change. Inside of our config, we are going to add a post HTML object underneath build. And all we have to do is use Outlook and say that we want to change its tag to MSO. And we go back to the digest.html inside of the build folder, we can see that now there's this Outlook. And the reason is because we didn't save our template. So for right now, it still thinks that we are using this Outlook element, and Mazel doesn't know what to do with that because we changed the purpose of that tag. So Mazel is just outputting that Outlook element in the resulting HTML. So if we change

know what to do with that because we changed the purpose of that tag. So Mazel is just outputting that Outlook element in the resulting HTML. So if we change this to MSO, well, that's going to fix that particular problem. If we go back and look at the digest, we can see now we have that conditional comment. And that's just the Outlook element. We can change just about any of the utility tags. Like for example, if we wanted to change fetch. So we can go back to our config, we can say that we want to change fetch, and we would want to use the get tag. But we might also want to change the attribute from URL to resource. We could do that as well. We can change the if tag, the each tag. We could change a lot of tags. So it's very, very configurable. And we can use whatever tags we want as long as we make

well. We can change the if tag, the each tag. We could change a lot of tags. So it's very, very configurable. And we can use whatever tags we want as long as we make the appropriate changes inside of our config. Now we can also add global variables so that we can use them inside of our layouts, inside of our templates, and inside of our components. All we have to do is just simply add them here. So let's say that we would have a companyName global variable, and we could just give it a value of myCompanyName. We would be able to access this companyName by using the page object. So let's do that inside of... where we would want to do that? I guess right here inside of our digest. So let's fill that message slot, and we will use the page object to get to the companyName. And whenever we view

do that? I guess right here inside of our digest. So let's fill that message slot, and we will use the page object to get to the companyName. And whenever we view that in the browser, there it is, my companyName. But we can also define what are called local variables. So if you think of the page object like the window object within the browser, that is the global object. And if you wanted to access a global variable, you would do so with window. and then that variable. We do the same with page. and then the variable. But, you know, a local variable inside of a function, we would just use the variable name. And we could do that here. Instead of saying page.companyName, we could just have companyName. All we have to do is modify our config to have this locals object, and then we just

here. Instead of saying page.companyName, we could just have companyName. All we have to do is modify our config to have this locals object, and then we just define our companyName here. The end result is going to be the same. We will end up with myCompanyName being displayed in our email, but now we can access that companyName without having to use the page object. Now, as I mentioned, config.js is the default config. This is for the development environment. There's also a production environment, and its config is config.production.js. And if we open that up, it's a little bit smaller. And if we compare the two, we will see that the production is leaving off some things. Like, for example, the templates. There is a templates inside of the

And if we compare the two, we will see that the production is leaving off some things. Like, for example, the templates. There is a templates inside of the production config, but only the destination path is specified. We can see that for the production environment, the built HTML documents would go inside of a folder called build_production. So this is the way configurations work. We have the default environment, and then we have other environments. We'll talk about other environments later, but the configuration for the other environment is layered on top of the default. So you can think of it kind of like the production environment is inheriting the config for the default environment, but it's overriding certain values like the

it kind of like the production environment is inheriting the config for the default environment, but it's overriding certain values like the destination path. But also notice that there are some other options here. Like, for example, inline CSS is set to true. And this is very important because in order to have the widest compatibility, we need to use inline CSS. But it's also important to remove any unused CSS. Because remember, these are email. They are being transmitted over the wire. So we need them to be as small as possible, meaning that we remove all of the unused CSS. So for our production environment, it is still inheriting everything else that we have set. So it is still inheriting the locals and the global company name. It's inheriting the MSO tag as a

is still inheriting everything else that we have set. So it is still inheriting the locals and the global company name. It's inheriting the MSO tag as a replacement for the Outlook tag. But it is overriding the destination path, and anything else that we set here. Now we can define other environments. All we have to do is just create a new config file. So let's say that we need an environment specifically for marketing emails. So we'll create a new config file called config.marketing.js. So the important thing here is whatever comes after config. So config.production is the production environment. config.marketing is the marketing environment. And let's say that the specific settings that we need are a different source folder for our templates.

Config.marketing is the marketing environment. And let's say that the specific settings that we need are a different source folder for our templates. So our marketing templates would be inside of marketing templates. And then of course the destination would be build marketing. And then we could build our emails using this environment by just changing our script. So we could add another npm script here that could be marketing. And then the value for that script will be mazel build marketing. And if we had the mazel CLI installed, it would be just simply mazel build marketing that we would have to type into the command line. But in order to successfully use that environment, we would need to create a marketing folder inside of source. And it would need its

into the command line. But in order to successfully use that environment, we would need to create a marketing folder inside of source. And it would need its own templates folder. And then inside of there we could create a marketing template.html. So mazel is extremely configurable, and we can configure it however we need to. We can change the folder structure, we can customize the utility tags that it gives us, and we can even define our own environments for specific settings. It really is a powerful framework.