@benjackwhite would be great to get your input on the bundling when you have a chance. Feel free to ignore the files outside of the '/react' folder - I'll clean these up tomorrow

@ivanagas here's the plan for the new react API:

• using feature flags: https://github.com/PostHog/posthog-js/pull/540/files#diff-3f9639244c4f35263ae8dca85e6e0192116557ced4ea7f4afadb2ca764a912fd
• doing events: https://github.com/PostHog/posthog-js/pull/540/files#diff-c150c8de1585c706c7d7ec0d0d566ba6a2ab92394c5782123820f190f9869b4f

The react native API has the hooks getFeatureFlag which is the same as isFeatureEnabled in the js library. And getFeatureFlags which is the same as the onFeatureFlags callback

However, with the payload function too I wonder if getFeatureFlag will be confusing for the JS SDK as I would expect that to return the payload. In this PR I've proposed staying close to the JS file naming:

• useFeatureFlag - returns the result of useFeatureFlagPayload if it exists, otherwise the result of useFeatureFlagEnabled
• useFeatureFlagEnabled - which uses isFeatureEnabled
• useFeatureFlagPayload - which uses getFeatureFlagPayload
• useFeatureFlags - which returns the callback from onFeatureFlags

@neilkakkar @EDsCODE and @liyiy what API do you want for the react feature flags?

Mind explaining re: useFeatureFlag, why is returning the variant key more confusing that returning the payload or the variant sometimes? 🤔

I think it links to the issues that Ben and I were mentioning

For the useFeatureFlag, if I was calling it and had a payload I'd expect it to return a payload - regardless of whether it's a multivariate or a boolean

Hmm, removing it means we end up missing a big piece of usefulness here, since right now there is no equivalent of posthog.getFeatureFlag(). You can somewhat get it from getActiveFeatureFlags, but that's missing the $feature_flag_called calls for experiments & audit.

I'll leave it up to you though!

If it helps, you can leave out useFeatureFlag, and instead have useFeatureFlagKey which maps to getFeatureFlag() ? That seems like a common ground?

Hmm, removing it means we end up missing a big piece of usefulness here, since right now there is no equivalent of posthog.getFeatureFlag(). You can somewhat get it from getActiveFeatureFlags, but that's missing the $feature_flag_called calls for experiments & audit.

Good point. I like the idea of a useFeatureFlagKey function or a useFeatureFlagVariantId however getFeatureFlag seems to return either a boolean or a string. I would have expected the key to always be a string?

Yeah, useFeatureFlagVariantKey is more accurate, instead of FeatureFlagKey which means the flag name that you're passing in 😓

The boolean is the variant key for a flag that has no variants (and responds with true), which exists for backwards compatibility iirc, but yeah for a flag with no variants you really shouldn't be calling getFeatureflag()

The boolean is the variant key for a flag that has no variants (and responds with true), which exists for backwards compatibility iirc, but yeah for a flag with no variants you really shouldn't be calling getFeatureflag()

I've just tried it and for a boolean value getFeatureFlag returns true if it's a boolean type. I'd have thought that the variantKey would be a string? I'm skeptical we'd want to return true/false for the VariantKey and have boolean in the type signature

I'd be keen to merge what we have so far and then in parallel I think you're still working through the proposal ben mentioned to streamline it to just getFeatureFlagPayload and getFeatureFlagVariantKey (unless you have reached a decision)

@neilkakkar if you agree, would you mind giving a final review of the PR including a check of the new removing event listener function I added

Didn't manually try it out, but I'm hoping you have! Code looks good

Size Change: +896 B (0%)

Total Size: 2.28 MB

_{compressed-size-action}

@neilkakkar based on our discussion I agree and it makes sense to add useFeatureFlagVariantKey - I've added that here: 7376f32 can you confirm you're happy with it?

@ivanagas and @pjhul we now have a react library! Would be awesome to get your help with updating the docs and older tutorials. I'll take a crack at some of them later too

@joethreepwood could be good to have some marketing support around this once we've updated the docs. Main benefit for users it that it makes implementation much easier/quicker.

Think it can go in the Changelog this week, or is this going to drift to next?

I'll update the docs to a good enough place by EOD that it can go in this week

@joethreepwood as discussed @pauldambra has a few more tweaks he wants to do so likely this will be next week instead

@joethreepwood as discussed @pauldambra has a few more tweaks he wants to do so likely this will be next week instead

I thought that was in reference to Dashboard templates, or is that the case here too?

I had the wrong tab open - my fault! Yep this is ready to go when the docs merge later today. Dashboard templates will need another week

I know its been a while since this was implemented - but I wanted to drop a note that I was recently tripped up by the decision to not set the initial state of the flag:

https://github.com/PostHog/posthog-js/blob/main/react/src/hooks/useFeatureFlagEnabled.ts#L7-L9

This results in users getting undefined and then getting the flag value - even when the flag value is known at startup. I stumbled upon this because of some undesired thrashing and rendering in our app.

IMO the workarounds should be on nextjs users or SSR users to maybe have a separate set of functions - and for everyone that does not care about SSR to not be hit with this behavior.