Anti-pattern: consuming code changing milo core blocks

[mokimo]

Description

Consuming projects should not change or rely on anything that's coming from milo core blocks. Markup might change, analytic tags might change, the loading order and timing of things might change, the element might stop existing completely due to introducing intersection observers...

Example

Let's assume there's consuming code that expects an anchor tag. If your consuming project has a hard dependency on an element within a block, your code would now be broken after the changes get merged.

<!-- Before, milo core marquee-->
<a class="video" href="https://adobe.com/video.mp4"></a>
<!-- consumer code: doSomething(document.querySelector("a.video")) -->

<!-- After, milo core marquee -->
<video> ... </video>
<!-- consumer code? ERROR -->

Why is it bad?

From a milo core perspective, maintenance get's very tedious as each change might be a breaking change now. Changes need to happen in a compatible way or in tandem with consuming projects. This is hard to coordinate with the CI/CD nature and ever-green consumption model.

From a consumers perspective, this can lead to CSOs and bugs as the pages with special features are rarely tested or even known to contributors.

How to avoid?

Option one (preferred)
The promise of milo is to centralize knowledge and benefit a larger community and range of projects. If you have a cool feature, it likely makes sense to advocate usage across different projects and shipping it as part of the milo core code-base.

Option two
Writing your own block. If a block is only used in your project and doesn't make sense in any other projects - you should write your own block. It's a lot easier to deprecate, maintain, change on a consumer level than it is in milo core where usage might be unknown or hard to find out reliably across all consumers.

What if we already rely on and change core blocks?

If your project already does this, at a minimum you should have a good range of nala tests covering the use-cases so that any developer that submits code for milo core, has instant feedback on his PR.
As a long term strategy, it's best to avoid this completely and refactor instances where this already occurs.

[overmyheadandbody]

Re: option 1 - consumers should always reach out when they have a special use-case. Milo Core might already have experience with the request from other consumers and might be able to advise or start thinking of some solutions that could fit everyone. Making assumptions just raises the entropy of the project, slowing down feature and value delivery to address issues that could have been discussed in the broader community in the first place.