mirror of
https://github.com/status-im/react-native.git
synced 2025-01-09 09:12:02 +00:00
4ffb241647
Summary: public Implement all the necessary glue code for several diffs submitted before to get Hot Loading work end to end: - Simplify `HMRClient`: we don't need to make it stateful allowing to enable and disable it because both when we enable and disable the interface we need to reload the bundle. - On the native side we introduced a singleton to process the bundle URL. This new class might alter the url to include the `hot` attribute. I'm not 100% sure this is the best way to implement this but we cannot use `CTLSettings` for this as it's are not available on oss and I didn't want to contaminate `RCTBridge` with something specific to hot loading. Also, we could potentially use this processor for other things in the future. Please let me know if you don't like this approach or you have a better idea :). - Use this processor to alter the default bundle URL and request a `hot` bundle when hot loading is enabled. Also make sure to enable the HMR interface when the client activates it on the dev menu. - Add packager `hot` option. - Include gaeron's `react-transform` on Facebook's JS transformer. The current implementation couples a bit React Native to this feature because `react-transform-hmr` is required on `InitializeJavaScriptAppEngine`. Ideally, the packager should accept an additional list of requires and include them on the bundle among all their dependencies. Note this is not the same as the option `runBeforeMainModule` as that one only adds a require to the provided module but doesn't include all the dependencies that module amy have that the entry point doesn't. I'll address this in a follow up task to enable asap hot loading (9536142) I had to remove 2 `.babelrc` files from `react-proxy` and `react-deep-force-update`. There's an internal task for fixing the underlaying issue to avoid doing this horrible hack (t9515889). Reviewed By: vjeux Differential Revision: D2790806 fb-gh-sync-id: d4b78a2acfa071d6b3accc2e6716ef5611ad4fda
41 lines
1.4 KiB
JavaScript
41 lines
1.4 KiB
JavaScript
/**
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
* All rights reserved.
|
|
*
|
|
* This source code is licensed under the BSD-style license found in the
|
|
* LICENSE file in the root directory of this source tree. An additional grant
|
|
* of patent rights can be found in the PATENTS file in the same directory.
|
|
*
|
|
* @providesModule BatchedBridge
|
|
*/
|
|
'use strict';
|
|
|
|
const MessageQueue = require('MessageQueue');
|
|
|
|
const BatchedBridge = new MessageQueue(
|
|
__fbBatchedBridgeConfig.remoteModuleConfig,
|
|
__fbBatchedBridgeConfig.localModulesConfig,
|
|
);
|
|
|
|
// TODO: Move these around to solve the cycle in a cleaner way.
|
|
|
|
const Systrace = require('Systrace');
|
|
const JSTimersExecution = require('JSTimersExecution');
|
|
|
|
BatchedBridge.registerCallableModule('Systrace', Systrace);
|
|
BatchedBridge.registerCallableModule('JSTimersExecution', JSTimersExecution);
|
|
|
|
if (__DEV__) {
|
|
BatchedBridge.registerCallableModule('HMRClient', require('HMRClient'));
|
|
}
|
|
|
|
// 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.
|
|
|
|
Object.defineProperty(global, '__fbBatchedBridge', { value: BatchedBridge });
|
|
|
|
module.exports = BatchedBridge;
|