Skip to content

[BUG] useFeature returns false directly when the return datafile indicates true #304

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task done
yslkmart opened this issue Mar 6, 2025 · 3 comments
Open
1 task done
Labels

Comments

@yslkmart
Copy link

yslkmart commented Mar 6, 2025

Is there an existing issue for this?

  • I have searched the existing issues

SDK Version

"@optimizely/react-sdk": "^3.2.2",

Current Behavior

I'm using useFeature hook to get the feature flag and later use react query to call diff endpoint per feature flag setting.

When the component renders, I get isEnabled returned from the hook as false but later on all true. The setting on the Optimizely end for the flag is true and I can see it from the returned datafile as well.

I also tried to use clientReady, but it was true ever since component rendered.

Is this the default behaviour? I'm expecting isEnabled to be undefined while the client sdk is processing the datafile to get the isEnabled state.

Thanks,

Expected Behavior

useFeature hook should return undefined while processing

Steps To Reproduce

just use useFeature hook for a specific feature

React Framework

"react": "^18.3.1",

Browsers impacted

No response

Link

No response

Logs

No response

Severity

No response

Workaround/Solution

No response

Recent Change

No response

Conflicts

No response

@yslkmart yslkmart added bug Something isn't working needs-triage labels Mar 6, 2025
@junaed-optimizely
Copy link
Contributor

Hey @yslkmart. Here are my findings on this -

  1. clientReady should not be ready from the beginning. And we made some changes regarding that. [FSSDK-10730] isClientReady logic adjustment #285. v3.2.3 contains the change. You are one patch short from that.
  2. useFeature is designed this way from the beginning. If the client is not ready, it returns false as a default. I can understand why that could be misleading. So Your proposal on using undefined instead of false might be a better idea. But I don't see it as a bug necessarily. It could be an enhancement request. I have created an internal ticket FSSDK-11245 to track this.

Thanks for the issue!

@junaed-optimizely junaed-optimizely added enhancement New feature or request acknowledged and removed bug Something isn't working labels Mar 6, 2025
@yslkmart
Copy link
Author

yslkmart commented Mar 6, 2025

@junaed-optimizely Thanks for the reply. I'm using ^3.2.2 so I think I'm actually using v3.2.3? but still clientReady is instantly true when component renders while isEnabled is false and in the datafile it's true.

So it sounds like getting isEnabled as false initially from useFeature is by design? In our case, we actually want three states for isEnabled i.e undefined when client is not ready, true and false when it is. Is there an existing workaround where we know when the client is not ready? clientReady doesn't seem to work. Currently, we just wait for a sec before reading isEnabled.

Thanks,

@junaed-optimizely
Copy link
Contributor

@yslkmart yes, in that case you are using 3.2.3. In that case you might be waiting for the client to get ready before rendering the component.

Either way, I think isEnabled should be undefined ( not false) while the SDK is calculating..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants