[Guidance] Best practice for code reuse in complex projects.

[weenzeel]

• Maizzle Version: 3.5.0
• Node.js Version: 14.15.1

I'm building an email template framework for my organization. And the documentation states that repetitive code should be extracted in to components.

@cossssmin Can you guide me on what is possible / best practice with Maizzle today for code reuse?

I've tried the approach ...

1. Use a base layout as a master for all templates.
2. Extend the base layout with a template per type of send out that we need.
3. Create a component hierarchy of nested components, e.g:

<component src="framework/wrapper.html">
    <component src="framework/card.html">
        <component src="project-a/card-content.html">
            <component src="framework/button.html">
            </component>
        </component>
    </component>
</component>

I'm having problems with the nested components. For the inner most component to be generic and reusable local data needs to be passed from card-content to the button. But this is failing to render in random ways when we pass local data to a component that is nested in another component (compilation sometimes fails to resolve a component to it's markup and just includes the component tag in the final markup). I've found other issues hinting that this is a bug caused by one of the dependencies of Maizzle.

So, using the hierarchy above as an example, the best we can do now is to nest components down to the first "stateful" component" and there reference global data from the layout (defined via a front matter or configuration file). Right?

Using the hierarchy above I would need to duplicate code for "button" to include it in different types of "card-content" with the correct reference to global data. Right?

Any hints on how to use the framework as intended for reusable abstractions is appreciated!

Thanks for making Maizzle available for us to try and use!

[cossssmin]

Can't offer much advice in this direction tbh, I've never done/needed to do such complex component nesting.

I've used Maizzle in projects that compiled over 100 templates (many of them sharing multiple, sometimes identical, sections) but never needed to extract more than a header/footer/hero/button to components that I didn't have to nest.

So my first concern here would be if I'm not perhaps doing premature abstractions - do you really need everything as a nested component? From my experience I almost never had to nest components - just add them here and there throughout the template. Not saying you shouldn't do it, this is just my experience.

That being said, Components in Maizzle are not that advanced right now (see #397 (comment)) - my advice is to think of them more like 'includes' and not like how you'd use them in something like Vue for example. Maybe I should have named them Modules, after posthtml-modules which provides this functionality 🤔

But this is failing to render in random ways when we pass local data to a component

See #369

And the documentation states that repetitive code should be extracted in to components.

We do say you can extract CSS components, but not that you should 🙂

P.S.: also have a look at extending templates - might be of use in your case.

[weenzeel]

Thanks @cossssmin for your response.

Good to know how I should think about components.

One of the big pain points of html email development is the endless nesting of tables. They make it hard to navigate your position in the tree. They make it hard to focus on content and iterate quickly. Being able to build your own abstractions that hides some of these nested tables would be really useful. Both for your self and for allowing content-oriented staff to do some "light" coding of email-templates themselves using the abstractions you've built.

A second pain point of html email development is all of the endless hacks. It's hard for a team to keep track of something strange is done in code with purpose or by misstake. If code can be hidden in abstractions, solutions and documentation can be hidden inside those abstractions. Making it easier to work together and onboard new members.

Thanks for taking the time to share some good insights! Impressed with Maizzle overall! 🙂

[daniel-thisnow]

I'm slightly ashamed to admit we used maizzle 0.2 for maybe almost 2 years, and nested like crazy. Not sure it was the best idea, but I liked it for these vml buttons. Got quite carried away with if else statements and colours etc. I only just worked out how to pass the page object up out of the component back to the top of the page, and finally if last.loop --> time to try and learn the equivalent in newer maizzle.

Now that the designs are more component based, its only really the button atm that is the heavily re-used item. As much as I'd like to to put it in a component, I need to access the local variables with the page object.