Skip to content
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

[FEATURE] export useOpenFeatureClientStatus #1036

Open
literalpie opened this issue Oct 15, 2024 · 6 comments · May be fixed by #1082
Open

[FEATURE] export useOpenFeatureClientStatus #1036

literalpie opened this issue Oct 15, 2024 · 6 comments · May be fixed by #1082
Labels
enhancement New feature or request

Comments

@literalpie
Copy link

Requirements

the hook in use-open-feature-client-status.ts would be useful, but is not exported. I'm not sure if this is intentional or not?

@literalpie literalpie added the enhancement New feature or request label Oct 15, 2024
@beeme1mr
Copy link
Member

Hey @literalpie, would the useWhenProviderReady hook satisfy your use case?

@literalpie
Copy link
Author

No, I'm checking for NOT_READY because I want to defer rendering of my feature flagged component until the loading state is finished (and I want to treat the error state fallback the same as ready)

It's simple enough to replicate the hook. I just opened the issue in case it's an oversight.

@toddbaert
Copy link
Member

Maybe I'm confused, but what you're describing is the intended purposed of the useWhenProviderReady hook, though it has some extras (to support suspense and re-rendering); you can disable these if you don't want them though.

@literalpie
Copy link
Author

literalpie commented Oct 16, 2024

useWhenProviderReady will return false if the status is ERROR or FATAL, or whatever. I want to treat that as true.

@toddbaert
Copy link
Member

useWhenProviderReady will return false if the status is ERROR or FATAL, or whatever. I want to treat that as true.

Ah, I see.

Ya in that case I can see the value. I think it would be nice to export this, but in that case I'd like it to have the behavior and features of or other public hooks (suspense, re-rendering, etc), like this. Does that make sense to you @literalpie ? That way our hooks have consistent features and options.

I can update the issue, and I'm happy to assign it to you if you'd like to work on it (no pressure though).

@literalpie
Copy link
Author

Sorry, I don't think I'll find time to work on this in the near term.

I'm also not sure I understand what you mean by "re-rendering" from other public hooks. Because this hook sets a "useState" state when the events happen, I think it will cause re-rendering as much as needed.

Also, because this hook is only getting the status of the client, and not doing any asynchronous work, I'm not sure suspense would be used. (but I rarely use suspense, so maybe I just don't understand right)

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

Successfully merging a pull request may close this issue.

3 participants