Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TNT-43012 Return default content items #802

Merged
merged 1 commit into from
Mar 9, 2022
Merged

Conversation

XDex
Copy link
Contributor

@XDex XDex commented Feb 4, 2022

Note: DO NOT MERGE until target-upstream v0.0.56 with support for characteristics -> scopeType is released to production.

Description

Support default content proposition items delivered for control experiences with no offer content.

Related Issue

https://jira.corp.adobe.com/browse/TNT-43012

Motivation and Context

Support default content propositions in the response, so that customers know when a control experience is selected.

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Improvement (non-breaking change which does not add functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA or I'm an Adobe employee.
  • I have made any necessary test changes and all tests pass.
  • I have run the Sandbox successfully.

@@ -41,7 +42,12 @@ export default ({ renderDecisions, decisionScopes, event, viewCache }) => {
scopes.push(PAGE_WIDE_SCOPE);
}

const schemas = [HTML_CONTENT_ITEM, JSON_CONTENT_ITEM, REDIRECT_ITEM];
const schemas = [
DEFAULT_CONTENT_ITEM,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the explicit nature of this PR.

I wish there was a way for Target Upstream to figure out which schemas to act on without a change to the Web SDK which enable us to add more schemas in the future without a change to the SDKs..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jfkhoury We can make an optimization in this regard in case when content for all available schemas should be retrieved by not specifying schemas array at all in the request - in this case content for all available schemas will be returned implicitly from Target Upstream.
Thus, only when the page wide scope is not included in the request would we need to set the schemas explicitly to all values other than DOM_ACTION. Let me know if this would be desired and I'll open a ticket for it..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@XDex the optimization you suggested would still require a code change when a new schema was added. Target upstream should know that only when the "view" scope is requested, it should return DOM_ACTION schemas. If this were the case the Web SDK would only need to be updated when new schemas needed to be handled by the SDK. Currently only redirect, and dom action schemas are handled. The rest are passed through.

If a new pass-through schema were added, this code would need to be updated even though the SDK isn't doing anything with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, let's just leave it as-is then for now, the schemas being always explicitly specified in the request.

@5amfung
Copy link

5amfung commented Feb 8, 2022

@XDex Your PR title is referring to the wrong TNT number.

@XDex XDex changed the title TNT-43421 Return default content items TNT-43012 Return default content items Feb 9, 2022
Copy link
Contributor

@ninaceban ninaceban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@XDex great job!
I saw you are checking that renderAttempted=false although there was nothing to render, and renderAttempted is confusing in this situation, it is an experience that was executed on the page because of the nature of __view__ scope. The customers are chaining the sendEvent promise to filter the executed experiences, collect the response tokens and send them to third parties.
I would say that in case renderDecisions=true we should add the renderAttempted=true flag and send a display notification.

@XDex
Copy link
Contributor Author

XDex commented Feb 10, 2022

@ninaceban As we discussed today, I'll wait for your A4T PR to get merged before adding the mods to mark default content items as renderable actions

@@ -41,7 +42,12 @@ export default ({ renderDecisions, decisionScopes, event, viewCache }) => {
scopes.push(PAGE_WIDE_SCOPE);
}

const schemas = [HTML_CONTENT_ITEM, JSON_CONTENT_ITEM, REDIRECT_ITEM];
const schemas = [
DEFAULT_CONTENT_ITEM,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@XDex the optimization you suggested would still require a code change when a new schema was added. Target upstream should know that only when the "view" scope is requested, it should return DOM_ACTION schemas. If this were the case the Web SDK would only need to be updated when new schemas needed to be handled by the SDK. Currently only redirect, and dom action schemas are handled. The rest are passed through.

If a new pass-through schema were added, this code would need to be updated even though the SDK isn't doing anything with it.

@XDex
Copy link
Contributor Author

XDex commented Feb 23, 2022

@ninaceban @jonsnyder I've implemented support for default-content items when renderDecisions=true, with proper grouping to view/mbox scopes, please take another look when you get a chance.
Note - This PR requires the support of characteristics -> scopeType to be released in Target upstream before being merged, see https://jira.corp.adobe.com/browse/TNT-43696
Thank you!

Copy link
Contributor

@jonsnyder jonsnyder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes look good. I would like Nina to review before we merge though.

Copy link
Contributor

@ninaceban ninaceban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@XDex Thank you Andrei. I see you have added a functional test, could you also add unit tests that assert a proper grouping of the decisions based on the use-cases:

  • default content item is returned for a view
  • default content item is returned for a decision scope
  • default content item is returned for __view__ scope

return {
pageWideScopeDecisions,
nonPageWideScopeDecisions,
viewScopeDecisions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why we need to return the viewScopeDecisions here?

decisionsGroupedByDomActionSchema.unmatchedDecisions
viewDecisions: viewScopeDecisions,
nonAutoRenderableDecisions: decisionsGroupedByRenderableSchemas.unmatchedDecisions.concat(
nonPageWideScopeDecisions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to keep the old order of extracting the decisions:

  1. Extract the redirect decisions by Redirect Schema(no changes needed).
  2. Extract from remaining decisions from step 1 the renderable decisions (by DOM_ACTION, DEFAULT_CONTENT_ITEM schema and scopeType: view).
  3. Extract page-wide scope decisions and viewDecisions from the renderableDecisions from step 2, by __view__ scope.
  4. Remaining decisions from step 2 are the form-based composed decisions.

Otherwise, it becomes extremely hard to understand why we group then concat at the end the decisions, then also maintain the code.

@jonsnyder jonsnyder merged commit 477503e into adobe:main Mar 9, 2022
@github-actions github-actions bot mentioned this pull request Mar 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants