Read ramp provider priority from the rampProviderPriority document - #6159
Draft
j0ntz wants to merge 3 commits into
Draft
Read ramp provider priority from the rampProviderPriority document#6159j0ntz wants to merge 3 commits into
j0ntz wants to merge 3 commits into
Conversation
Handle the nullish case of ignoreExpiration explicitly, which strict-boolean-expressions promotes to an error once the file leaves the warning suppression list.
The affiliate provider ordering read promoCards2 through filterInfoCards, which meant behavior config had to be a display card hidden behind empty localeMessages. It now reads rampProviderPriority, which carries ordering and nothing else. Matching moves into a pure function so it can be unit-tested without a store. An entry matches on installerId OR an active promotion, rather than requiring both to agree when both are present, so a user who picked up the promotion after installing elsewhere is no longer excluded. The edge-info-server bump is to an unpublished version; the lockfile follows once it publishes.
The doc described affiliate ordering as a read of promoCards2 through a card with empty copy. That mechanism is gone, so the hook section, the info server configuration blocks, decisions 10.5 and 10.6, the glossary and the testing items now describe the rampProviderPriority document, with a phase 4 entry recording what diverged.
Contributor
Author
📸 Test evidencebaseline no promo
promo activated
paybis first
Captured by the agent's in-app test run (build-and-test). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Technical Design Document
ramps-deeplink-provider-priority.md
CHANGELOG
Does this branch warrant an entry to the CHANGELOG?
Dependencies
https://github.com/EdgeApp/edge-info-server/pull/161
This PR is red until that one merges and publishes. It bumps
edge-info-serverto an unpublished^3.14.0, sonpm installfails withETARGETand every downstream check with it. The lockfile bump follows the publish.Requirements
No visual changes: this reorders an existing list, it does not alter any component.
Description
Asana: https://app.asana.com/0/1215088146871429/1217207276378713
Moves the ramps affiliate provider ordering off
promoCards2and onto the info server's newrampProviderPrioritydocument.The read this replaces went through
filterInfoCardsrather thangetDisplayInfoCardsspecifically so that a card withlocaleMessages: {}could configure ordering and never render. That made behavior a display card wearing a disguise, which is why dismissing a visible card hid the ad but left its ordering running.What changed:
useRampPreferredProvidersreadsinfoServerData.rollup?.rampProviderPriority. ThefilterInfoCardsread is gone; the function itself stays, since the promo carousel still uses it.src/util/rampProviderPriority.tsas pure functions, so the rules are unit-testable without a store. An entry matches oninstallerIdor an active promotion, rather than requiring both to agree when both were present, which had excluded a user who picked up the promotion after installing from somewhere else.getActivePromoIdsnow unions thepromoCards2-derived ids with therampProviderPrioritykeys that apply. Without this the split would be incomplete:activePromotionswas derived from cards alone, so a promo code naming a document entry was dropped on entry and again at every login, and the only way to activate one would have been to keep a display card alive purely to name its promo id.src/docs/ramps-deeplink-provider-priority.mdis updated to the new mechanism, with anedge-info-serverdesign section and a phase 4 history entry.Testing
17 new unit tests in
src/__tests__/util/rampProviderPriority.test.tscover the OR match, per-direction scoping, country include/exclude, date windows, an unparseable date, dedupe across entries, and the promo-id derivation. Full suite: 99 files, 720 tests, 107 snapshots, plustscandeslintclean against a locally built copy of the dependency.On the iOS sim, in a throwaway account, driven end to end with the document hard-coded locally in place of the server response (the deployed info server does not serve it yet), so the real matching and ordering code ran against it. Screenshots below: the option list with no promotion, the code activated in Promotion Settings, and the same list reordered.
The middle screenshot is also the evidence for the
getActivePromoIdschange. Before it, Promotion Settings accepted the code and listed nothing.