is there a way to work with library without the hook api ?

[a-eid]

is there a way to simply work with the api without the hook api like so.

if(!isInitialized){
  await initialize()
}

await discoverReaders()
await connectReader(...)

I think the hook api decision was misfortune, as it complicates things .... it would've be so much easier.

thanks.

[dakkor71]

+1 for this idea!

[UrbanChrisy]

I initially built using the hook api and it was so complicated to get going not recommended.

Agree with the hook being a bad design choice.

I will be rebuilding and importing the functions directly import { } from '@stripe/stripe-terminal-react-native/src/functions'

If you look this is what is used under the hood in the hook.

Then create event emitter listener for the events coming from the native side.

const eventEmitter = new NativeEventEmitter(
  NativeModules.StripeTerminalReactNative
);

I will be rewriting the implementation in app I work one. This will probably happen next week. I can post what I end up with after.

Edit:

I've been pushed onto something else might be another week or two.

[jackdewhurst]

I'm very up for this idea too. I've run into a few issues with the hook api and would like to create my own hook without needing to put all of this stripe stuff in a view component.

[nabilfreeman]

I spent a few hours writing an imperative service style implementation of this library without using hooks today - focusing on Tap to Pay on iOS since that is our use case.

The main reason I wanted to give it a try it because I was not comfortable with the excessive API load that the library adds by requesting connection tokens even on screens which are nothing to do with payment (e.g. every time somebody downloads your app and launches it, even if they don't log in, your API must ping Stripe and generate a fresh connection token).

After trying and failing, personally I would strongly not recommend going down this route, due to the complexity of the eventEmitter and the single-use nature of the connection tokens.

This is a layer on top of native modules which is a layer on top of the iOS Terminal SDK (didn't even look at Android yet), and there is just so much abstraction that it's not intuitive to interact with this library. A lot of the decisions made in this library were probably necessities due to the existing codebase in the vanilla SDKs.

But just to give you an example of the complexity... you fire a request to find some readers, and then you must listen for several events. First the SDK emits an event asking for a new token. You then call another promise to set the token within 60 seconds. Then it emits more events as it discovers readers, and then another event when it finishes so you know when to resolve the original promise.

All of this as singletons (it shouldn't be a class instance, because on the native level the SDK is run as a singleton).

If you want to see my sins take a look here: https://gist.github.com/nabilfreeman/e537bc59b57958ce6d79840dcdf36586

I am now back on the provider + hooks and using a different workaround to avoid the extra connection token requests

[Gorenjai]

It'd also be great if there was a way to do 2 more things with the SDK.

1. Check whether the hardware supports tap to pay (localMobile version) and
2. Open up the terms and conditions popup without triggering reader discovery [I'm not fully sure if the apple implementation allows for this but on the assumption that it does, it'll be great to take the user through a nice UX in this way]

[nazli-stripe]

@Gorenjai you can check the hardware support using the new supportsReadersOfType method on beta.19: https://github.com/stripe/stripe-terminal-react-native/releases/tag/v0.0.1-beta.19

[Gorenjai]

@Gorenjai you can check the hardware support using the new supportsReadersOfType method on beta.19: https://github.com/stripe/stripe-terminal-react-native/releases/tag/v0.0.1-beta.19

Amazing. This is great news! Thanks :)

[a-eid]

@UrbanChrisy is it a good idea to start using @stripe/stripe-terminal-react-native/src/functions instead of the useStripeTerminal hook ?

[UrbanChrisy]

@a-eid For my use case I found that using these functions directly gave me better control on what I wanted the UI/UX to do. Plus they are still wrapped in stripes own trace functions, so no loss of data there. Just where and when these functions get called is upto my control.

I don't really see anything wrong with it, only just means you to have to catch every edge case that you want to catch.

We also found that when connecting to a reader it can unexpectedly disconnect if the underlying reader software needs updated. So we wanted to listen to when this would occur to show some UI to the user indicating as such.

I also found that wrapping the whole app in the Stripes provided context wrapper would re-render our app so often it became a source of slowness.

[UrbanChrisy]

@a-eid I have created a gist of a dumbed down implementation if you would like to reference. The beef of the logic is in stripe-terminal.ts file - check it out here

Its a boatload of code ngl. But the end result was a tap to pay reader that would auto connect and be ready for our users to use almost always immediately when the user needs it. Our use case is waiters in restaurants.