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

chore: RN provider and hooks attempt 2 #321

Merged
merged 24 commits into from
Nov 30, 2023
Merged

Conversation

yusinto
Copy link
Contributor

@yusinto yusinto commented Nov 30, 2023

This is a second attempt of #306 using the newly added event source.

  • use StreamingProcessor and event source to fetch flags
  • added LDProvider
  • added hooks
  • added typed variation[Detail] functions

Please read the example README and try running the example app.

Copy link

This pull request has been linked to Shortcut Story #221870: Implement RN provider api.

Comment on lines 40 to 47
const unsupportedType = useMemo(
() => ({
value: defaultValue,
variationIndex: null,
reason: { kind: 'ERROR', errorKind: 'UNSUPPORTED_VARIATION_TYPE' },
}),
[defaultValue],
);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is my proposed fix for this comment in #306 .

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think this will do it. 👍

@@ -40,7 +40,7 @@
"ios": "yarn ./example && yarn build && yarn ./example ios"
},
"peerDependencies": {
"react-native": "*"
"react": "*"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need react for useMemo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only alphabetically re-ordered the members of this interface, no change in functionality here.

Comment on lines -5 to -16
/**
* In react-native use base64-js to polyfill btoa. This is safe
* because the react-native repo uses it too. Set the global.btoa to the encode
* function of base64-js.
* https://github.com/beatgammit/base64-js
* https://github.com/axios/axios/issues/2235#issuecomment-512204616
*
* Ripped from https://thewoods.blog/base64url/
*/
export const base64UrlEncode = (s: string, encoding: Encoding): string =>
encoding.btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to common so this can be shared.


/**
* Creates the client object synchronously. No async, no network calls.
*/
constructor(
public readonly sdkKey: string,
public context: LDContext,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm decoupling the construction of LDClient instance and identify. The idea is to allow an LDClient object to be constructed, and at a later time call identify to fetch flags. We seem to be getting many requests for this and for the rn sdk, this seems to work ok.

} catch (error: any) {
this.emitter.emit('failed', error);
throw error;
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems redundant because identify does the same work. It is a breaking change so I am calling it out here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the failed functionality was not replaced.

I think the fundamental flow is also different.

So a ready/failed event was a singular activity. The SDK wouldn't emit ready more than once. You people put code there that they want to execute once the SDK is ready to go. Or when they know it will never be ready, failed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are just basic tests for now. I will add more soon in a separate PR.

Copy link
Member

@kinyoklion kinyoklion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your tests seem like maybe they have an open handles problem and are failing.

It would be nice to have some amount of documentation on each of the hooks. To provide some intellisense so developers no what to expect.

I am continuing to look through other parts, but looks reasonable so far.

@yusinto
Copy link
Contributor Author

yusinto commented Nov 30, 2023

tests seem like maybe they have an open handles

Yep. The issue was EventProcessor was actually trying to send events. I have set sendEvents: false for unit tests to fix this. Thank you for checking.

const ldClient = useLDClient();
const { status } = useLDDataSourceStatus();

if (status === 'ready') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is error a terminal state? This is concerning.

Typically we always want the client to be used, we generate unknown flag events. If it goes from good to bad we also have cached events.

Or maybe the status needs explained. My reflex is this is problemati.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. I did this originally to avoid valuation errors caused by a null/undefined ldClient. This was early in the iteration when using polling. The Provider now requires an ldClient instance so that means we can fallback to the ldClient by default. I have made this change now.

@yusinto
Copy link
Contributor Author

yusinto commented Nov 30, 2023

documentation on each of the hooks

Good idea. These hooks call the ldClient variation methods, which are fully documented there. I think we should link them somehow so we only maintain 1 copy? I'm not sure how to link them though.

@kinyoklion
Copy link
Member

documentation on each of the hooks

Good idea. These hooks call the ldClient variation methods, which are fully documented there. I think we should link them somehow so we only maintain 1 copy? I'm not sure how to link them though.

Well, to make actual links you can do {@link LDClient.variation} for example. It isn't ideal because it will literally link you to the item.

I am not sure, cross package, if there is a way to insert the docs inline. With inheritance you can inherit them, but doesn't help for hooks.

@yusinto
Copy link
Contributor Author

yusinto commented Nov 30, 2023

documentation on each of the hooks

Ok I duplicated the comments and also added comments for the base hooks. There were mistakes in the LDClient docs as well and I corrected those too.

@yusinto yusinto merged commit a343c83 into main Nov 30, 2023
15 checks passed
@yusinto yusinto deleted the yus/sc-221870/rn-provider-hooks branch November 30, 2023 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants