EDsCODE
commented
1 year ago Possible opportunities for 3:
- The code snippets execute and show result of calling the snippet
- Exposure/call stream. We've discussed this and there's possibly some event volume issues but I don't think we should write it off because of that. We can create a dedicated table that acts as logging for these events. The ability to see a log/graph of calls will give a lot more confidence to the flag working
annikaschmid
Is your feature request related to a problem?
We often receive a lot of support questions around more complicated feature flags implementations as we support multiple functionalities across many client and server side libraries.
Our docs are helpful in explaining all of this but it can still be difficult to figure out exactly what you need from it and sometimes users don't want to read through pages of documentation to get things up and running.
This includes:
Describe the solution you'd like
A short questionnaire wizard to help users determine what library they're planning to use and if they need any other setups (local eval, bootstrapping) within the feature flag creation screen. It'll then show the exact instructions or docs to follow for it.
Updated docs and tutorial examples. @ivanagas has been doing a great job at this with tutorials like https://posthog.com/tutorials/canary-release. It would be nice to add one or two more variations (like with JSON payloads or server side local eval/bootstrapping)
TBD: A way for users to check their feature flag implementation and that they're receiving events with that feature flag without having to navigate to /events or /insights to do that
Describe alternatives you've considered
Additional context
Thank you for your feature request – we love each and every one!