Complex stencils

[jeffkamo]

Continuing our discussion from #113: how should complex stencils and their variations be managed?

[jeffkamo]

@ry5n to continue what we were discussing, re: multiple components vs. one component + variants...

When you refer to variants, do you mean our traditional component + modifier format? For example...

c-product
c-product.c--reservation
c-product.c--fixed-cta
c-product.c--multi

Or do you mean something like...

c-product
c-product--reservation
c-product--fixed-cta
c-product--multi

[ry5n]

Yes, I meant the traditional component + modifier format for styling. For JS, it would mean something like subclassing (I think). By leaning towards multiple ui components, what I’m getting at is that “product” is a high-level type of thing, where different use cases should not necessarily share implementation. Having a single implementation + modifiers is much easier with existing, lower-level components because each expresses a particular design pattern rather than a more abstract entity like “product”.

[kpeatt]

@ry5n yeah I'm inclined to agree. I don't think variations are the same as modifiers — they may share the same markup, they may use entirely different markup, they may share the same CSS, etc. Do we want to maintain the same naming scheme for those things?

[ry5n]

I don’t think so. I’d consider them different components, even though they might be a way to represent the same kind of entity. At first blush I’d go with something like Jeff’s initial suggestion in #113:

c-product-something
c-product-something-else
c-product-other

I’m a little bit shy having a “canonical” implementation, hence avoiding c-product.

[ry5n]

Another strategy would be to break down this type of thing into a set. So c-product-header-priced could be a standard lockup with product name to the left and pricing (including reg. price, savings, sale price) to the right. Then we leave it to the developer to compose their PDP with these pieces (and others). Conceptually:

<div class="some-wrapper-probably">
    <ProductHeaderPriced/>
    <ProductHeroCarousel/>
    <Rating/>
    <ProductForm></ProductForm>
    <Accordion></Accordion>
</div>

[jeffkamo]

I don't mind that idea. Making our product pages composable in this manner might help reduce the bloat from having so many near-duplicate copies of just c-product-blah.

It would also allow us to deal with edge case client sites on a per-project-basis:

<div class="wrapper">
    <CustomReservationForm />
    <ProductHeroCarousel />
    ...the rest could be the same, or ordered differently
</div>

[kpeatt]

What does the implementation of the set have to do with the naming of complex stencils?

I think we're going to run into a lot of situations where there are 'standard' implementations of a pattern and there are variations. There are also going to be situations where there is no standard and we'll have to be more descriptive. Is the suggestion that we should always just be descriptive and not bother with variation naming?

[ry5n]

Probably at this point the proof is in the pudding. While commenting here I’ve been thinking of building PDPs, which are often more variable than, say, PLPs. So maybe we should keep all of it in mind and come back to this when we have tried a few out. Those two templates might be good test cases. We already have one to work on back in #113. Does that seem reasonable?

[jeffkamo]

Technically a naming convention is only part of this discussion. Complex stencils are themselves the topic.

Anyway, I just don't want us to kick ourselves when we want to customize something slightly but can't because our templates might be so monolithic and inflexible, that any customization will result in having to start (almost) from scratch.

Maybe this isn't any kind of requirement, but it would be nice if we could work in a way to allow designers some flexibility how components/subcomponents can be ordered.

Not sure if this is a good or bad idea, but maybe using blocks can help?

<div class="c-product-whatever">
    {+productHeader}
        <ProductTitle />
        <ProductPrice />
    {/productHeader}

    {+productBody}
        <ProductForm />
    {/productBody}

    {+productFooter}
        <ProductAccordion />
    {/productFooter}
</div>

[ry5n]

I just don't want us to kick ourselves when we want to customize something slightly but can't […]

Yeah same.

As far as using blocks go, I think the issue is that they are effectively global, so you can’t use them for anything that repeats… could be wrong.

[kpeatt]

Yeah, I think we should definitely be taking advantage of all of the modularity that Dust offers. I understand the structure argument better now. I was picturing composite stencils working pretty much exactly like what you have laid out above Jeff — with the potential for more structural markup being added.

I don't think we need to address full template composites yet — those will likely follow a similar pattern to how our composite stencils get created.

[kpeatt]

Is the Product component in #113 meant to be a PDP replacement? I haven't looked at it yet but assumed it was a Product in the sense of something that would appear in Recommended Items carousel or in a grid on a PLP.

[ry5n]

Seems like it’s most of the PDP.

[ry5n]

For things that may appear in lists/collections, I would recommend we choose names like “product-teaser”, “product-tile” or similar.

[jeffkamo]

As far as using blocks go, I think the issue is that they are effectively global, so you can’t use them for anything that repeats

Correct, we can't use blocks for components we iterate over – actually there are workarounds, but they are convoluted and a bit gross.

[nastiatikk]

Haven't seen this topic previously. Want to share my other concern about Stencil complexity:

When Stencil component is missing something that project design has you need to check three places instead of one:

1. SCSS component in the bower/stencil
2. Component variables in variables.scss
3. Create project component with the same name as bower/stencil component and write missing styles there

[nastiatikk]

Even if there is no need in updating component with missing styles it is still inconvenient and inconsistent to have styles spread through different places in the project (and cloud in case when they're default).

When you inspect lets say button element on the page and see that button has blue background colour, where will you go to change it? First you'll go to the button component and will find that there is no button component. When you didn't find button component you'll go to variables.scss, what may have tens of other replaced component variables (what is another mess).

Though it may be not a big deal when you built the project and know it. But what if you just jumped on it and your task is to replace this button colour? It may take a while to get that blue is default style, because there is no place in the project where you could see it.

Things would have been more simpler if somehow we could see all project components in a one place.

[nastiatikk]

After reading @ry5n comment in PR 121 I got another concern regarding the way we install and use Stencil.

If component was imported to some project and occasionally we need to work on that project but the component was removed, we will stuck on reinstalling or updating or something else that may take much longer then the original ticket issue.

Won't it be more useful to have all of the components in the project and connect only those that are used? I don't know how things are with Bootstrap now but as far as I remember this is how it was there 2 years ago. Of course it will limit us with the project updates, but we don't move all mobify projects to adaptive projects, do we? And if you see that a project requires those updates you'll just do this. Basically it will be up to you - update or not update, depending on the issue.

[nastiatikk]

That will also fix that issue when you make a local component update and make PR and then this PR is not merged for 2 months and then you forget about that and when the PR is finally merged you don't update your styles because you're already working on the other project. I believe that was the main @avelinet issue?

[ry5n]

If component was imported to some project and occasionally we need to work on that project but the component was removed

This would be helped if each component was in its own repo, then we leave the repo and just mark it as legacy.