Replies: 1 comment
-
I understand your need. This is not that trivial in the frontend side of things, because the frontend SDK does not evaluate feature flags, and offload that work to the upstream API (frontend API or Edge). In order to support this behavior we would need to extend the protocol to accept a list of values. This also yields questions around whether it is considered ORed (as long as one value match) or ANDed (all values must match). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
There is a core functionality that differs between front-end and back-end clients regarding checking if a flag is enabled or not, which affects how we use the tool.
We have a case where users participate in several groups and those groups need to be matched in the targeting. We created a constraint called "group", and this works like a charm in the backend using isEnabled and passing the group in the enhancedContext, to check one by one those groups, not quite good, but it works.
But for the front-end client, there is no context for isEnabled, instead, the context is controlled elsewhere and generates a request for the backend for each context that is changed causing the application to become slow given the several group permissions that users have to check.
Is there a way to make this check against a list instead of a single value for example:
Group constraing targeting in unleash interface (ABC, DEF)
User in frontend in groups (ABC, XYZ)
Without changing the context between ABC and XYZ:
Would be perfect to make something like
Beta Was this translation helpful? Give feedback.
All reactions