[Discussion] Consider adhering to Node-style callbacks or Promises for async NativeModule methods

[ide]

The NativeModule methods that take callbacks currently expect to receive an error handler and a success handler. I believe it would be good if they adhered to a de facto convention.

Promises would probably be best since they work with existing promise libraries and ES7 async/await. Since NativeModule methods are async anyway this makes sense to me. Node-style callbacks ((err, result) => ...) are OK too and has similar benefits around being able to use existing helper libraries.

[vjeux]

Yeah, we're not really fan of the current state of the world but it's working and haven't been a high enough priority so far.

I really like promises API for that, but I'm a little worried that they run in a setTimeout. Maybe we can just create a fake promise api that just calls then and catch directly.

Tangential to that, we need to figure a better way to represent the error object. Right now it's free for all. Would also be nice to have a stack trace attached.

I'd like to get @sahrens, @jordwalke, @frantic opinion but if they are alright, I'd love for you to promisify the bridge :)

[sahrens]

Real error objects would be great. AsyncStorage returns pseudo error objects and the JS facad turns them into proper errors. Would be great if our modules were consistent.

-Spencer

On Mar 20, 2015, at 12:22 PM, Christopher Chedeau [email protected] wrote:

Yeah, we're not really fan of the current state of the world but it's working and haven't been a high enough priority so far.

I really like promises API for that, but I'm a little worried that they run in a setTimeout. Maybe we can just create a fake promise api that just calls then and catch directly.

Tangential to that, we need to figure a better way to represent the error object. Right now it's free for all. Would also be nice to have a stack trace attached.

I'd like to get @sahrens, @jordwalke, @frantic opinion but if they are alright, I'd love you to promisify the bridge :)

—
Reply to this email directly or view it on GitHub.

[frantic]

Also note that because we control the bridge we can have async stacktraces support easily, so I wouldn't say setTimeout/setImmediate usage is a concern. Imho the biggest disadvantage of promises is that it's really easy to forget to catch the error.

[ide]

Imho the biggest disadvantage of promises is that it's really easy to forget to catch the error.

Yeah. I think promises are ok and versatile in some scenarios but not always the API I'd directly want to use. The reason I lean towards them is that they're going to be the lingua franca of asynchrony in JS so to speak, and it will be easy to use promises with callback APIs / promise libraries / ES7 async functions.

[ide]

Fixed by #1232 / 90439ce. RCT_EXPORT_METHOD now can export JavaScript functions that return promises and are compatible with async/await.