fix: react context no longer changes on flag change

[joker23]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

sdk-1792

Describe the solution you've provided

• change the use variation hooks to register on change listeners
• changes in flags no longer changes the ldclient context

Describe alternatives you've considered

I think this change may require a major version, but we can probably avoid that with some compromises.

Additional context

There is a testing gap here and I will create some tasks to address. I want to do this in a different PR because I would like to refactor RN unit test to use https://oss.callstack.com/react-native-testing-library/ instead of the react testing library.

We also need to revisit the detox test, from some research it seems like detox is the correct technology for e2e testing, but we may want to revisit how to plug in to the sdk test harness (and deprecate the example testing)

---

Note

Medium Risk
Changes core flag-evaluation hooks to manage subscriptions and state updates; incorrect listener cleanup or dependency handling could cause missed updates or leaks, though the change is localized to the React Native SDK.

Overview
Prevents flag updates from changing the React context value by removing provider-level change listeners and memoizing the { client } context value in LDProvider (deleting setupListeners).

Adds per-flag subscriptions in useTypedVariation and useTypedVariationDetail that initialize local state, listen on change:${key}, and update only when the evaluated value/detail actually changes (using fastDeepEqual), rather than relying on provider re-renders. Tests are updated accordingly, including removal of the now-obsolete setupListeners unit test.

^{Written by Cursor Bugbot for commit eba484e. This will update automatically on new commits. Configure here.}

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 25394 bytes
Compressed size limit: 26000
Uncompressed size: 124693 bytes

[github-actions]

@launchdarkly/browser size report
This is the brotli compressed size of the ESM build.
Compressed size: 171382 bytes
Compressed size limit: 200000
Uncompressed size: 798175 bytes

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 23334 bytes
Compressed size limit: 25000
Uncompressed size: 81070 bytes

[github-actions]

@launchdarkly/js-client-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 18984 bytes
Compressed size limit: 20000
Uncompressed size: 98086 bytes

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[kinyoklion]

I am tempted to say we should add a listener for context changes as well. Which then trigger a re-evaluation, but won't end up changing state if the value is the same.

I was doing some testing in flutter and that ended up being the sweet spot with providers to ensure that each context appeared correctly in an audience.

[joker23]

I think this is reasonable, but that might alter the API here since the original hook would only return the flag value. Not sure if it would be confusing if a state update is dispatched on context change without being able to get the actual changed value?

We can introduce a new hook for the context value (or say to use the react context with getContext()). Don't think there is a really good answer to this, honestly. You will have potentially varying behaviors depending on the flag value type because I think react will not dispatch an update if the setState is called on a value that is equivalent to the previous state value.