Make persisting optional

[dferber90]

Summary

• breaks getFlags by changing it from getFlags(user) to getFlags({ user })
• introduces a persistUser option to useFlags and getFlags and makes persisting users in HappyKit opt-in
• introduces an application-wide default setting called persistUsers to configure()

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 via useFlags({ persistUser: true, user: { key: "xxx" } }). For example, you can use this to only persist team members by setting persistUser on a per-user basis: useFlags({ persistUser: isTeamMember, user: { key: "xxx" } }).

getFlags supports the persistUser option too. To enable this, getFlags now accepts an object similar to useFlags.

BREAKING CHANGE

• breaks getFlags by changing the API from getFlags(user) to getFlags({ user })

[dferber90]

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.