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

Support for top and bottom of page events. Combine personalization display notifications together. #1036

Merged
merged 23 commits into from
Sep 21, 2023

Conversation

jonsnyder
Copy link
Contributor

@jonsnyder jonsnyder commented Sep 14, 2023

Description

Changes to functionality:

  • New boolean option in sendEvent to control sending the display notification. If this is false, the display notifications are saved to be included in a future event. (This is useful for top of page events.)
  • Another new boolean option in sendEvent to control including delayed display notifications. (This is useful for bottom of page events.)
  • Create a new proposition format for empty viewChange notifications.
  • When sending an event for a view change with no decisions, the display notification is included in the original event.
  • When rendering specific scopes or surfaces, and page wide decisions, these notifications are combined.

Additionally, this PR includes extensive refactoring of the personalization component. The key changes are:

  • An immutable proposition object wrapper with accessors that includes some of the proposition business logic.
  • I overhauled the view decisions cache. It now accepts all the returned view propositions, updates its cache, then returns the propositions for the current view. Additionally, when a view cache is empty for a view name, it returns a synthesized proposition to communicate an empty view change.
  • I split out rendering into a set of schema keyed processors. This can be easily extended when Web SDK supports more item schemas.
  • I added component level tests for personalization so that I could compare the current functionality to the refactor.

Related Issue

https://jira.corp.adobe.com/browse/PDCL-9860

Motivation and Context

I had much of this in #1025, but then after some comments from Nina and Jason I was able to make this much more simple. I mistakenly made the updates to the top and bottom branch, but now that it is done, it doesn't make much sense to separate them.

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.

Sorry, something went wrong.

@jonsnyder jonsnyder changed the title Support for top and bottom of page events. Support for top and bottom of page events. Combine personalization display notifications together. Sep 14, 2023
@jasonwaters
Copy link
Collaborator

👍

.eql({
propositions: [
{
scope: "noView",
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
scope: "noView",
scope: "noview",

Needs to be lowercase to match #1027.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nope, this shouldn't be lowercase. I have added a comment to the previous merged PR too. We shouldn't change the event triggered by the customer. The viewName will be lowercase only by Personalization component to store/get from cache. Data Collection should not be impacted by the Personalization logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is what I did here: ca33032. The lowercase logic now only resides in the viewCache when saving and matching view decisions.

)
.eql([
{
scope: "noView",
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
scope: "noView",
scope: "noview",

Needs to be lowercase to match #1027.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for bringing this up. I've made a different change so that the lowercase scope is only used in the view cache. ca33032

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.

None yet

4 participants