status-im
/
react-native
mirror of https://github.com/status-im/react-native.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
react-native/Libraries/BatchedBridge/BatchedBridge.js

29 lines
848 B
JavaScript
Raw Normal View History

[ReactNative] Refactor BatchedBridge and MessageQueue Summary: @public The current implementation of `MessageQueue` is huge, over-complicated and spread across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory` Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge` is only an instance of it. Test Plan: I had to make some updates to the tests, but no real update to the native side. There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer. Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable. Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls. Test the failure callback on the `Geolocation` example. All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
/**
* Copyright (c) 2015-present, Facebook, Inc.
*
Update license headers for MIT license Summary: Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs. find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$ replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree. Reviewed By: TheSavior, yungsters Differential Revision: D7007050 fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
2018-02-17 02:24:55 +00:00
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
[ReactNative] Refactor BatchedBridge and MessageQueue Summary: @public The current implementation of `MessageQueue` is huge, over-complicated and spread across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory` Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge` is only an instance of it. Test Plan: I had to make some updates to the tests, but no real update to the native side. There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer. Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable. Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls. Test the failure callback on the `Geolocation` example. All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
*
Prettier React Native Libraries Reviewed By: sahrens Differential Revision: D7961488 fbshipit-source-id: 05f9b8b0b91ae77f9040a5321ccc18f7c3c1ce9a
2018-05-11 02:06:46 +00:00
* @format
Adding flow strict local to remaining possible files in xplat/JS Summary: ag -L --ignore __snapshots__ 'flow strict|noflow|generated|The controller you requested could not be found.' | ag '\.js$' | xargs ag -l 'flow' | sort > ~/temp cat ~/temp | xargs ag -L 'flow strict' | xargs sed -i '' 's/flow$/flow strict-local/' until flow check; do flow check --json | jq -r '.errors[].message[0].path' | sort | uniq | xargs hg revert; done allow_many_files The controller you requested could not be found. The controller you requested could not be found. Reviewed By: TheSavior Differential Revision: D9004573 fbshipit-source-id: 936bd5741706b781be06bf08b6ad805a69407dfd
2018-08-09 15:32:04 +00:00
* @flow strict-local
[ReactNative] Refactor BatchedBridge and MessageQueue Summary: @public The current implementation of `MessageQueue` is huge, over-complicated and spread across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory` Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge` is only an instance of it. Test Plan: I had to make some updates to the tests, but no real update to the native side. There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer. Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable. Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls. Test the failure callback on the `Geolocation` example. All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
*/
Prettier React Native Libraries Reviewed By: sahrens Differential Revision: D7961488 fbshipit-source-id: 05f9b8b0b91ae77f9040a5321ccc18f7c3c1ce9a
2018-05-11 02:06:46 +00:00
[ReactNative] Refactor BatchedBridge and MessageQueue Summary: @public The current implementation of `MessageQueue` is huge, over-complicated and spread across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory` Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge` is only an instance of it. Test Plan: I had to make some updates to the tests, but no real update to the native side. There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer. Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable. Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls. Test the failure callback on the `Geolocation` example. All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
'use strict';
Decouple Module System from Native Calls Summary: The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies. Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version. The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object. Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub. I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge. executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works. The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense. The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native. Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does. That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle. This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD. public Reviewed By: vjeux Differential Revision: D2717535 fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
2015-12-08 23:57:34 +00:00
const MessageQueue = require('MessageQueue');
Add remote API to uninstall the global error handler in RN Reviewed By: fromcelticpark Differential Revision: D6426209 fbshipit-source-id: 804e73e0dc4e4b85b336e3627c00840d2ff3c9d6
2017-12-11 15:59:45 +00:00
Replace RN exception handling override with new version Reviewed By: Hypuk Differential Revision: D7385541 fbshipit-source-id: 287d3f4d681046f740ed0552e00a2249c3803a0b
2018-04-03 12:59:07 +00:00
const BatchedBridge = new MessageQueue();
[ReactNative] Refactor BatchedBridge and MessageQueue Summary: @public The current implementation of `MessageQueue` is huge, over-complicated and spread across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory` Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge` is only an instance of it. Test Plan: I had to make some updates to the tests, but no real update to the native side. There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer. Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable. Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls. Test the failure callback on the `Geolocation` example. All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
Decouple Module System from Native Calls Summary: The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies. Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version. The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object. Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub. I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge. executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works. The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense. The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native. Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does. That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle. This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD. public Reviewed By: vjeux Differential Revision: D2717535 fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
2015-12-08 23:57:34 +00:00
// Wire up the batched bridge on the global object so that we can call into it.
// Ideally, this would be the inverse relationship. I.e. the native environment
// provides this global directly with its script embedded. Then this module
// would export it. A possible fix would be to trim the dependencies in
// MessageQueue to its minimal features and embed that in the native runtime.
Update some JS in preparation for some Jest updates. Summary: * Next version of Jest doesn't allow non test files in __tests__ folders. * I'm trying to switch all tests off of jsdom on react-native. This should save 500ms of time when running a single test because jsdom is slow to load and react-native is also not supposed to run in a DOM environment, so let's not pretend we are providing the DOM in tests. * Make the bridge config configurable so that when we disable automocking and we reset the registry we can redefine the value. Oh also, stop using lodash in Server.js. First off, lodash 3 doesn't work in Jest's node env because it does some crazy stuff, second because we don't need to load all of lodash for debounce. Reviewed By: davidaurelio Differential Revision: D3502886 fbshipit-source-id: 1da1cfba9ed12264d81945b702e7a429d5f84424
2016-06-30 08:57:30 +00:00
Object.defineProperty(global, '__fbBatchedBridge', {
configurable: true,
value: BatchedBridge,
});
Decouple Module System from Native Calls Summary: The JavaScript ecosystem doesn't have the notion of a built-in native module loader. Even Node is decoupled from its module loader. The module loader system is just JS that runs on top of the global `process` object which has all the built-in goodies. Additionally there is no such thing as a global require. That is something unique to our providesModule system. In other module systems such as node, every require is contextual. Even registered npm names are localized by version. The only global namespace that is accessible to the host environment is the global object. Normally module systems attaches itself onto the hooks provided by the host environment on the global object. Currently, we have two forms of dispatch that reaches directly into the module system. executeJSCall which reaches directly into require. Everything now calls through the BatchedBridge module (except one RCTLog edge case that I will fix). I propose that the executors calls directly onto `BatchedBridge` through an instance on the global so that everything is guaranteed to go through it. It becomes the main communication hub. I also propose that we drop the dynamic requires inside of MessageQueue/BatchBridge and instead have the modules register themselves with the bridge. executeJSCall was originally modeled after the XHP equivalent. The XHP equivalent was designed that way because the act of doing the call was the thing that defined a dependency on the module from the page. However, that is not how React Native works. The JS side is driving the dependencies by virtue of requiring new modules and frameworks and the existence of dependencies is driven by the JS side, so this design doesn't make as much sense. The main driver for this is to be able to introduce a new module system like Prepack's module system. However, it also unlocks the possibility to do dead module elimination even in our current module system. It is currently not possible because we don't know which module might be called from native. Since the module system now becomes decoupled we could publish all our providesModule modules as npm/CommonJS modules using a rewrite script. That's what React Core does. That way people could use any CommonJS bundler such as Webpack, Closure Compiler, Rollup or some new innovation to create a JS bundle. This diff expands the executeJSCalls to the BatchedBridge's three individual pieces to make them first class instead of being dynamic. This removes one layer of abstraction. Hopefully we can also remove more of the things that register themselves with the BatchedBridge (various EventEmitters) and instead have everything go through the public protocol. ReactMethod/RCT_EXPORT_METHOD. public Reviewed By: vjeux Differential Revision: D2717535 fb-gh-sync-id: 70114f05483124f5ac5c4570422bb91a60a727f6
2015-12-08 23:57:34 +00:00
[ReactNative] Refactor BatchedBridge and MessageQueue Summary: @public The current implementation of `MessageQueue` is huge, over-complicated and spread across `MethodQueue`, `MethodQueueMixin`, `BatchedBridge` and `BatchedBridgeFactory` Refactored in a simpler way, were it's just a `MessageQueue` class and `BatchedBridge` is only an instance of it. Test Plan: I had to make some updates to the tests, but no real update to the native side. There's also tests covering the `remoteAsync` methods, and more integration tests for UIExplorer. Verified whats being used by Android, and it should be safe, also tests Android tests have been pretty reliable. Manually testing: Create a big hierarchy, like `<ListView>` example. Use the `TimerMixin` example to generate multiple calls. Test the failure callback on the `Geolocation` example. All the calls go through this entry point, so it's hard to miss if it's broken.
2015-06-17 14:51:48 +00:00
module.exports = BatchedBridge;