"passing" content and behaviour from personnalization to merch-cards block

[npeltier]

hi,

i'm working on creating a new 'replaceCard' action in personalization.js which impact will mostly be to register those personalisation actions in merch-cards.js block.
I wonder how i should achieve this not to pollute personalization code with commerce code (that would be importing a function from merch-cards into personalization).
Should i write something to localStorage? to the DOM?

[chrischrischris]

I think the cleanest approach is to add a replaceMerchCard action to personalization.js. The selector field would not be used to "find" a merch-cards block on the page, but would instead be used to specify which card to be replaced. The experience column would have the fragment path to the new card to be used.
replaceMerchCard would have a bit of code to take this info and attach it to the merch-cards block. Either as data- attributes, or just directly on the element. Then merch-cards.js would handle the loading of the fragment html and merging / replacing it in the merch-card json data.

[yesil]

replaceMerchCard would have a bit of code to take this info and attach it to the merch-cards block

This step sounds unnecessary to me.
MEP could simply expose the logic and merch-cards.js could check and update its internal set of cards.
This would avoid any kind of DOM manipulation during MEP processing.

replaceMerchCard | catalog.photoshop | /fragments/x/y/z

while merch-cards.js processes the query-index result, based on the card type, it can swap the card matching with the name.

cc: @chrischrischris @npeltier

[npeltier]

Hey @chrischrischris time has passed a bit, and as we discussed how to adapt to @vivgoodrich recent changes, on exposing only "replace" action to editors that would adapt for merch-cards, i realise that initital proposal from @yesil could basically be a better fit than adding ugly "if" per selector that would pollute personalisation code with lazy import, or specific query (if selector contains merch-cards):

1. define a clear identifier of the fact an action is custom, either "custom" column, or "customReplace" and others actions, or set of custom selectors define in some metadata / json file,
2. if action is identified as custom per 1, then do nothing at personalisation, but exposing it in session storage, or in the dom,
3. when it's time for whatever block to render it accesses that space defined in 2. and if any custom personalisation is at stake, it does its custom thing.

wdyt?

[chrischrischris]

I like this approach. Some MEP info is stored in config.mep so we could def put things in there. I wonder if there should be an action called custom-blockname-action which would then get that row of information stored in config.mep.custom.blockname: { action, restOfDataHere }. Then MEP doesn't care what happens, but the block is responsible to check for the mep data and any logic. the mep object still will provide any variant match, but the block doesn't necessarily have to use it.

[npeltier]

Do we event want <blockname>? Same custom action could be consumed by different blocks no?

[chrischrischris]

I'd think it'd be confusing if there is a custom action and every block has to decipher if it's intended for itself? Or are you suggesting that it would be based off the selector?

My idea is that if the action starts with custom- then that is parsed into the config.mep.custom object, so we aren't generating a bunch of new actions, just a new custom- one.

[npeltier]

Or are you suggesting that it would be based off the selector?

yes! and may be other details of the action

My idea is that if the action starts with custom- then that is parsed into the config.mep.custom object, so we aren't generating a bunch of new actions, just a new custom- one.

yes if action is custom- (or have custom flag set to true), it's just put into there and that's it. Personalisation is just responsible of adding that info for the audience it detected

[vgoodric]

Sorry @npeltier , did not notice this conversation. Looks like @chrischrischris has posted stuff from our discussions already. Here's my proposal:

1. Don't clutter the action list. In particular, I suspect we will eventually want to support remove and insert as well. So if we add an action, it will likely mushroom.
2. Put the data in the config.mep object. We have a similar setup for the fragment autoblock to be able to find needed data
3. Expand the simple selectors feature (new feature to make selecting elements easier for authors) to recognize "cards". I'm currently leaning towards something like "photoshop merch-card". This would eliminate the need for the new card fragments to always follow a specific naming pattern/location.
4. As for where to put the new block code, I think we can do something similar to what I recently did in fragments: check for the custom object and then import the code if needed.

I needed to focus on getting the big action overhaul across the finish line last week. My plan is to code the MEP portion for you guys and either have you adapt your previous code to my updates or review with you so I can adapt it for you.

[npeltier]

hey @vivgoodrich actually, most of it has already been done in #1999 it's just that we were not happy with yet another action, nor with too much specific code in personalization. The 3. aspect is already handled and something better for our editors. Basically a merch card web component is built out of selected fragment and we take the name property out of it to match the one in the collection. Thus, adding both a fragment and a selector would be content duplication in some way.
Hence my plan was just that mep / personalization has a certain flag or action prefix where it understands that nothing has to be done but to be put in config.mep. So, yes, config.mep.custom talked with @chrischrischris was sounding good to me.
(and finally i'm happy contributing to this :) )

[npeltier]

so i met with @vivgoodrich and we agreed on finally (quoting Vivian :) ):
1 no new action
2 selector will be off of a keyword (maybe merchcard or merch-card-collection
3 the actions that have the right selector will be added to config.mep.custom.merchCardCollection.replace (or something like that)