feat: add custom context fields to Unleash #11730
Conversation
- appPlatformOS: "ios" | "android" | "web" | # to allow targeting based on platform - appVersion: "8.67.0" # to allow targeting based on semVer constraints - userRoles: "user,team" # to allow targeting based on user role (for example, rolling out to all Artsy staff)
| @@ -11,6 +13,12 @@ export const WrappedFlagProvider: React.FC = ({ children }) => { | |||
| const storageName = (name: string) => `unleash-values:${name}` | |||
|
|
|||
| const config: IConfig = { | |||
| context: { | |||
| properties: { | |||
| appVersion: DeviceInfo.getVersion(), | |||
There was a problem hiding this comment.
Should we be using the version attribute within app.json instead? Looks we use that when generating our user agent string. When running in a simulator, DeviceInfo.getVersion() doesn't properly return a known version number but we still use this utility function in a few places, including the About screen.
There was a problem hiding this comment.
DeviceInfo.getVersion() retrieves the version of the app installed from the store. That's probably why we don't see a correct version when running in a simulator.
Do we use version number from app.json anywhere?
There was a problem hiding this comment.
We're currently using the app.json value to construct the user agent string (source). Maybe not very significant before but we're now using that value in Metaphysics to alter the homeView content returned.
There was a problem hiding this comment.
FYI – I opened another PR to bring more consistency to how we determine the current app version, preferring the app.json value based on this Slack conversation.
Holding on this change until that PR is resolved – then I'll rebase here.
Yes, exactly. You have to define these properties in the Unleash admin UI for them to show up as targeting options. And while Unleash doesn't directly support arrays of strings, we can use a comma-separated value in an "includes" clause for role targeting. Also interesting to find that they have specific semVer constraints that you can apply to a semVer version value. |
I know you can define segments in the Unleash UI which can persist a group of constraints and give it a name. So for Onyx, we can define a named Onyx segment with those userIDs preconfigured. But with user roles we can also define an "Artsy Staff" segment. |
|
I am in favour of this approach - will be really useful |
Description
This is meant as a conversation starter – not something on the critical path for feature development.
Reflecting on recent Unleash-backed A/B experiments, it would be nice to update the targeting for an experiment so that a certain group is always given the
experimentvariant. For example the members of a specific product team or all Artsy staff members (as identified via theteamrole).We've recently built some handling into Metaphysics (artsy/metaphysics#6297 and artsy/metaphysics#6465) to support returning Home View content only when the client is requesting from a supported app version. It seems like we can do similar targeting for Unleash feature flags (including experiments), if we pass along an appVersion context field.
The updated API request params to the Unleash backend look a bit like this:
PR Checklist
To the reviewers 👀
Changelog updates
Changelog updates
Cross-platform user-facing changes
iOS user-facing changes
Android user-facing changes
Dev changes
Need help with something? Have a look at our docs, or get in touch with us.