feat: switch and parallel running for DUP logic #2201
Merged
Conversation
This file contains 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
digitalcora
force-pushed
the
cfg-dup-logic-switch
branch
from
5a8700f to
98a258a
Compare
cmaddox5
approved these changes
Sep 13, 2024
| // such as `return { ...response, data: response.variants[variant] }`, but | ||
| // the compiler can't work out that the types are compatible. Maybe check | ||
| // this again once we upgrade to TypeScript 5. | ||
| const copy = { ...response }; |
There was a problem hiding this comment.
We already have lodash available so maybe could replace this with _.set or a similar function?
There was a problem hiding this comment.
I'm not quite getting how that would simplify things, considering we shouldn't mutate response itself here since it is a React-managed state value.
digitalcora
force-pushed
the
cfg-dup-logic-switch
branch
from
98a258a to
75c23da
Compare
|
Good call on testing the DUP packaging process, I hadn't done that before so it was also a good opportunity to see how it works. It looks like the package still works as it should! |
Introduces the concept of a "variant", which is an alternate candidate generator for an app ID. Also introduces a variant for DUPs which will be used to build and test the new departures logic. For now, this only generates a set of placeholder elements. Variants can be enabled via: * Adding a `variant=NAME` query param to a screen URL. The resulting screen page will fetch and display data for only that variant. * Enabling the "variant switcher" in the admin Inspector. This allows toggling between variants instantly without refreshing data; the data hook uses a special `all` value to request and hold onto the data for all variants at once. Additionally, `ScreenData` functions have an option to run and serialize all variants that exist for the app ID in parallel, in the background, without waiting for or doing anything with the results. This means we can have all existing screens constantly running the new logic at every step of the implementation, giving us more confidence that the final rollout would go smoothly. For now, we only use this option on "normal" screen requests (not pending, not simulation).
digitalcora
force-pushed
the
cfg-dup-logic-switch
branch
from
75c23da to
2f6eb78
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Introduces the concept of a "variant", which is an alternate candidate generator for an app ID. Also introduces a variant for DUPs which will be used to build and test the new departures logic. For now, this only generates a set of placeholder elements.
Variants can be enabled via:
Adding a
variant=NAMEquery param to a screen URL. The resulting screen page will fetch and display data for only that variant.Enabling the "variant switcher" in the admin Inspector. This allows toggling between variants instantly without refreshing data; the data hook uses a special
allvalue to request and hold onto the data for all variants at once.Additionally,
ScreenDatafunctions have an option to run and serialize all variants that exist for the app ID in parallel, in the background, without waiting for or doing anything with the results. This means we can have all existing screens constantly running the new logic at every step of the implementation, giving us more confidence that the final rollout would go smoothly. For now, we only use this option on "normal" screen requests (not pending, not simulation).