Closed dferber90 closed 3 years ago
This will be solved differently in the upcoming version of @happykit/flags
.
In cas anybody is reading this, persisting users has been disabled in the backend, but will be possible again with the upcoming @happykit/flags
.
Summary
getFlags
by changing it fromgetFlags(user)
togetFlags({ user })
persistUser
option touseFlags
andgetFlags
and makes persisting users in HappyKit opt-inpersistUsers
toconfigure()
Details
When you send a user to HappyKit with
useFlags({ user: {key: "xxx"} })
that user is stored in HappyKit, along with all the provided attributes. This is done so you're able to see the users of your flags in the HappyKit dashboard.Whether you persist a user or not doesn't affect how that users flags are evaluated. It is purely done to provide more complete data in the HappyKit Flags Dashboard.
Until now all users were always stored in HappyKit Flags automatically. However, sites with high user counts wouldn't want to flood their dashboard with all their users. Instead, they might want to send individual users only (like team members).
To enable this, persistent users are now opt-in. You can set this via
configure({ persistUsers: true })
globally, or on a per-user basis viauseFlags({ persistUser: true, user: { key: "xxx" } })
. For example, you can use this to only persist team members by settingpersistUser
on a per-user basis:useFlags({ persistUser: isTeamMember, user: { key: "xxx" } })
.getFlags
supports thepersistUser
option too. To enable this,getFlags
now accepts an object similar touseFlags
.BREAKING CHANGE
getFlags
by changing the API fromgetFlags(user)
togetFlags({ user })