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

[Bridge] Order of callbacks on native bridge modules is backwards #186

Closed
ide opened this issue Mar 24, 2015 · 4 comments
Closed

[Bridge] Order of callbacks on native bridge modules is backwards #186

ide opened this issue Mar 24, 2015 · 4 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@ide
Copy link
Contributor

ide commented Mar 24, 2015

The JS (BatchedBridgeFactory & MessageQueue) expects the last two arguments of async bridge methods to be errorCallback, successCallback:

        var onSucc = hasSuccCB ? lastArg : null;
        var onFail = hasErrorCB ? secondLastArg : null;

but the RCTBridgeModules define successCallback:errorCallback:. This isn't causing any issues - pointing it out mostly in case it causes confusion down the road.

@vjeux
Copy link
Contributor

vjeux commented Mar 24, 2015

Good catch. @jordwalke attempted to always have error callback THEN success callback. The motivation was to never forget the error callback but this introduced more confusion than anything and didn't pick up. There are still some remaining of this attempt here and there.

@sahrens
Copy link
Contributor

sahrens commented Mar 24, 2015

There is no way to enforce which is which so any method can rename them how it wants. We should probably just rename the vars in the bridge impl to cb1 and cb2.

On Mar 24, 2015, at 8:59 AM, Christopher Chedeau notifications@github.com wrote:

Good catch. @jordwalke attempted to always have error callback THEN success callback. The motivation was to never forget the error callback but this introduced more confusion than anything and didn't pick up. There are still some remaining of this attempt here and there.


Reply to this email directly or view it on GitHub.

@ide
Copy link
Contributor Author

ide commented Mar 24, 2015

It might be worth keeping some structure and documenting the (successCallback, errorCallback) convention. One benefit of the convention is that it makes the migration towards Promises / ES7 async functions (the discussion in #172) easier. Concretely the migration layer could roughly look like this:

function promisifyLegacyBridgeMethodThatHonorsConvention(method) {
  return function() {
    var context = this;
    var args = Array.slice.call(arguments);
    return new Promise((resolve, reject) {
      // Assume last two args to the legacy method are the success and error callbacks
      // by convention... might need a wrapper function that massages the args into a form
      // that resolve/reject expect but this is the gist of the idea
      args.push(resolve);
      args.push(reject);
      method.apply(context, args);
    });
  };
}

@brentvatne brentvatne changed the title Order of callbacks on native bridge modules is backwards [Bridge] Order of callbacks on native bridge modules is backwards May 31, 2015
@ide
Copy link
Contributor Author

ide commented Jun 12, 2015

Fixed by #1232 / 90439ce. The callbacks in the bridge code consistently go (successCallback, errorCallback), which now matches most of the built-in native modules. And with promises the callback arguments are entirely hidden.

@ide ide closed this as completed Jun 12, 2015
@facebook facebook locked as resolved and limited conversation to collaborators Jun 12, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

4 participants