Solution design for interactive merch cards

[yesil]

As part of Plans/twp migration to Milo, we aim to develop stateful merch cards and modals with different variations.
We plan to create a new Milo consumer repository to host the associated features and blocks.

Currently, the same offers are displayed as cards on CC product pages or as plan switcher on DC.

CC:

DC:

However, the user experience on CC and DC lacks interactivity compared to Plans cards.
Such as the ability to add or remove stock, change the plan type, etc.

Stateful, interactive Plans card

Subscription panel(modal) on Plans

Also, Plans gets more and more feature like upgrade flow, entitlement aware buy now/download buttons etc.

In order to provide the same user experience on all surfaces, we have considered two potential solutions during our due diligence:

1. Consolidating common code in Milo:
   Merch card and subscription panel(modal) logic would move to Milo.
   This approach involves coding most of the Plans/twp in Milo.
   We could explore using feature branches and periodic merging to the main branch
   in order to reduce the number of PRs to main branch.

2. Importing merch blocks from CC and DC:
   Provide a map of block name and provider url and load the block dynamically as needed.
   While this is currently an unsupported use case, we would appreciate community feedback on this approach and whether there are any strong reasons not to pursue it.

Please share any thoughts or alternative suggestions you may have.

[npeltier]

We could explore using feature branches and periodic merging to the main branch
in order to reduce the number of PRs to main branch.

as discussed offline, i wonder if some process like this does not already exists and if we should not talk about it in a separate dedicated thread, typically @chrischrischris 's personalization took quite some time before being PRed, and then merged

[yesil]

it is not a one shot feature though. Plans will be a living application with frequent change requests from business.

[3ch023]

could you please give more details about second approach (Importing merch blocks from CC and DC)?
I didn't understand who will be importing CC/DC merch blocks.

[yesil]

I'm thinking about importing merch blocks from Offers in CC and DC.

[npeltier]

in general we have a dependency for reuse on consonant, and how "compliant" each application wants to get. I'm afraid this is not at our level this will be handled though

[yesil]

Will wait for feedback from US.
@auniverseaway @chrischrischris

[auniverseaway]

However, the user experience on CC and DC lacks interactivity compared to Plans cards.

Where are the JIRA tickets asking for more interactivity in CC & DC projects that map 1:1 to your use cases?

If we do have real requirements from other projects with real go-live dates associated with these features, the features should obviously be built in Milo. DC is notoriously touchy about rolling out new UX without testing into it... so I would be shocked they have these uses.

I also wouldn't hesitate to start out in your own project, though... Franklin code is much more portable than AEM. You can bring it up to Milo if we do have needs in other projects.

Importing merch blocks from CC and DC

I don't think this is a good idea as it introduces a lot of complexity, risk, and potential performance issues.