Lazy fragments

[yesil]

For Merch cards with a subscription panel modal, I would like to reference the modal content with a fragment as shown in the screenshot. However, I want the fragment not to be processed.

The processing of the fragment should be be initiated by the block code on user interaction.
The fragment (last link in the block) content should be processed with the regular Milo pipeline with placeholders, personalization, etc.

I'm planning to simply remove the link attribute and render it as a text and parse the link in the frontend.

Although for a single card in a page it doesn't make big difference in performance, with a lot of cards (e.g: plan or catalog pages) the goal is to keep number of fetch calls low.

Any recommendations on the approach? Thanks.

[fullcolorcoder]

I'm planning to simply remove the link attribute and render it as a text and parse the link in the frontend.

It seems like this could be a fragile in authoring. If an author is to control this and it's not default behavior maybe it could be handled similar to the DNT hash?

[yesil]

I also thought about #_dnt hash first, but then checked the code and there are many 2 special clauses for it.
Adding a new use case would increase the code complexity.

On the other side, if the authors forget to remove the link attribute, the merch card logic can be implemented to handle it gracefully.

[auniverseaway]

I would like to reference the modal content with a fragment as shown in the screenshot. However, I want the fragment not to be processed. However, I want the fragment not to be processed.

1. The screenshot is a word document, not a modal. Also, the link shown does not have a hash.
2. Modal fragments are not loaded until you request them (typically a hashchange or a url with a hash).

The processing of the fragment should be be initiated by the block code on user interaction.
The fragment (last link in the block) content should be processed with the regular Milo pipeline with placeholders, personalization, etc.

I'm planning to simply remove the link attribute and render it as a text and parse the link in the frontend.

Although for a single card in a page it doesn't make big difference in performance, with a lot of cards (e.g: plan or catalog pages) the goal is to keep number of fetch calls low.

Any recommendations on the approach? Thanks.

Maybe I don't understand the request, but it sounds like you need to do more research on how Milo creates modals. As stated above, all modal/fragment loading is on-demand.

Now, getting to your title: "lazy fragments" which is very different than the modals (I think) you're discussing above...

We don't typically introduce complexity until we hit a limit in what we are trying to build. Meaning: if you haven't seen a performance issue with the current fragment solution, you probably shouldn't be exploring making it more complicated. It's great you have a hunch that there may be some problems in the future, but you should be able to make a page, see where the issues are with the current solution and iterate based on that feedback. Until you make that page and have the performance data, I wouldn't write any extra code or make your solution more complicated.

On the flip side, I do think it's a worthwhile discussion that if we have 100+ fragments that are direct on page (not modals), we should be asking ourselves if we should be that cruel to the environment.

[yesil]

@auniverseaway, the screenshot represents a WIP block proposal for defining a merch card with an associated subscription panel modal.

Perhaps I'm misunderstanding the request, but it seems that more research might be necessary regarding how Milo creates modals. As previously mentioned, all modal or fragment loading is handled on an on-demand basis.

The context here is related to Plans modals.
In our current AEM implementation, these are not authored as regular modals but are activated programmatically.
There is a requirement to pass specific data between the Card and the modal during initialization and closing, such as plan types, stock checkbox value and quantity for CCT/STE.

If we decide to utilize Milo modals for merch cards, GWP will need to assign unique names to each modal for the hash.
I will confirm this approach with PM/GWP in the upcoming Milo Commerce call.

To facilitate the data exchange between the card and modal, we can consider using the milo:modal:loaded and milo:modal:closed events.

On the flip side, I do think it's a worthwhile discussion that if we have 100+ fragments that are direct on page (not modals), we should be asking ourselves if we should be that cruel to the environment.

The plans page has ~17 cards but the Catalog page has many cards (200+), each containing little content.
GWP has a hard requirement to author each card individually in separate documents.
For plans I'll see how it performs with 17 fragments.
For catalog, we haven't discussed it yet but assembling them with an index and loading them from there sounds like good idea, at least worth trying.

Thanks for your detailed answer.