Extract React Native layer into module

[halseth]

For easy use of lnd wihin other apps, we could extract the react native layer into a module that could be easily be fetched.

• Pull the iOS (https://github.com/lightninglabs/lightning-app/tree/master/mobile/ios/lightning) and Android (https://github.com/lightninglabs/lightning-app/tree/master/mobile/android/app/src/main/java/com/lightningapp) native code into react native module.
• Extract relevant JS code that defines the API: https://github.com/lightninglabs/lightning-app/blob/master/src/action/grpc-mobile.js
• Nice to have: The iOS code should get runtime or autogenerated method inspection, currently the lndmobile API is mapped manually: https://github.com/lightninglabs/lightning-app/blob/master/mobile/ios/lightning/LndReactModule.m#L118

[otech47]

Extract relevant JS code that defines the API

Started looking into this step first and I understand how the mobile app is calling the grpc interface. Then I thought it could be worth trying to adopt some of the patterns from https://github.com/alexbosworth/ln-service as function name wrappers versus the sendCommand function. Obviously a convenience feature but RN devs may appreciate it

@alexbosworth any afterthoughts you had with your approach or if you see any pitfalls here would be helpful to consider

..., currently the lndmobile API is mapped manually:

@halseth the android version makes use of a method that seems to eliminate the need for manual mapping. Do you know if/why the iOS version can’t work similarly? Would be a bit cleaner but if that hasn’t been explored yet I can check why there’s a difference there

[alexbosworth]

I like my wrapper function but it may not be for everyone because I also restructure and rename a fair portion of the API

[alexbosworth]

One of the most difficult things about this approach though is that the LND API is not versioned and it's further split up into separate APIs which you can't really know if they are enabled or disabled since there is no call to tell you which features were built into the LND build.

So if you are making something general purpose to be used by different projects, you will face a matrix of different LND versions and different activated LND APIs.

Sometimes fields are repurposed or moved around and LND dev is fast moving, so it's not like you are on firm ground - lots of stuff is also basically deprecated but the replacements are also not really ready to go either

[halseth]

@halseth the android version makes use of a method that seems to eliminate the need for manual mapping. Do you know if/why the iOS version can’t work similarly? Would be a bit cleaner but if that hasn’t been explored yet I can check why there’s a difference there

I only did it for Android since I don't have that much experience with reflection on iOS. So I haven't explored whether we could do something similar on iOS. (knowing that Obj-C is a very dynamic language my hunch is that it is possible).

I marked it a nice-to-have, as it is not essential, but would make maintaining the module easier :)

[otech47]

@alexbosworth I imagined as much thanks for the insight! I think the barebones implementation without that overhead would be fine for now, even though I also really like that kind of wrapping functionality

@halseth okay good to know I can explore it further

I think I can make some progress on this over the weekend and I appreciate the feedback!

[nicolasburtey]

I'm building a react-native based app. The code is not open source yet (it will be at some point). This would have been helpful for me to have this at the beginning.

I'm also thinking to work on a hooks system that could make use of lnd easier in the context of a react-native based app build with functional components. somehow like https://github.com/react-navigation/hooks but for lnd. or https://github.com/alexbosworth/ln-service but for react-native. I'll post more here when I'll have something to share.

[otech47]

Found a project that might have a good scaffolding for this: https://github.com/coreyphillips/react-native-lightning

Just forked it to see what could be useful.

Also started on a work-in-progress git repo trying to set up an RN package using https://github.com/brodybits/create-react-native-module so I'll try and push that up soon with maybe an outline of what pieces might go where.

I suppose there is an eventual step of publishing the repo on the NPM registry and importing the package into this repo for a full end-to-end test but not quite there yet..

[halseth]

Found a project that might have a good scaffolding for this: https://github.com/coreyphillips/react-native-lightning

Ah, yeah that looks similar to what I had in mind! Tagging author here @coreyphillips, maybe we can join efforts.

[coreyphillips]

Hey @halseth. I'd be happy to. LND development is so fast, making this project a bit dated, so I'll have to update it with what I've been working on recently. Should be able to do that soon.

My initial plans for the project were the following:

• Have it working with the latest version of lnd (v0.9).
  • I believe there was some chatter regarding this in the mobile slack channel recently.
• Submit it as an npm package where, ideally, all the dev needs to do is yarn add react-native-lightning and drag/drop the lndmobile .framework/.aar files to a pre-specified location.
  • The example component would be packaged in there as well.
• Create some clean documentation to demonstrate how to init, backup, recover a wallet/channel(s) along with how to use each method, etc.
  • I was going to use the chakra-ui getting started page as a guide/starting point for this.

What were you thinking?

[halseth]

@coreyphillips woops, forgot to reply!

Yeah, that was more or less exactly what I was thinking! Since the react-native parts of the app is easy to keep in sync with the newest lnd releases when it lives in this repo, it would be nice to have such an npm package as a separate project that could be easily dragged in :)