Repository navigation
Auto-refresh simulator #5
Description
Activity
Yes. We need to port that over. Expect it in a few days/weeks.
I was thinking about this yesterday. A solution (although not optimal) would be to run a server locally in the simulator and have some process watch the local files and tell the simulator server that it should refresh. I was specifically looking at swisspol/GCDWebServer.
@a2 this is an interesting approach. We already have a solid filewatcher on the server so it might be easier to do it there. The current solution that we have is that the client keeps polling the package and checking for changes. It works well. But it's a little bit janky. If we can open a persistent connection to the server and the server can ping the client to refresh once a file changes (and a package has been updated) would be ideal. In the future, this would also help us in doing things like hot code swapping.
Why not leverage existing solutions like Webpack and webpack-dev-server? It does what you described. It uses chokidar for watching. The client code learns by a socket that update is available and either refreshes (without hot reloading), or does the hot reloading thing if it's configured.
See also #10 (comment) where I also rant about not using Webpack.
Webpack doesn't understand our module infrastructure out of the box. We have plans to support different module formats and different compilers. Additionally chokidar has so many problems but it's suffice to say it doesn't work on large codebases like ours. Regardless, we should get to a place where you decide what packager/module to use on the server.
Webpack doesn't understand our module infrastructure out of the box.
Do you mean custom stuff like package-scoped “global” filenames? This can probably be done with a plugin. Or is it too vastly different?
Additionally chokidar has so many problems but it's suffice to say it doesn't work on large codebases like ours.
They fixed a lot of issues in 1.0. I used to find it unreliable for months, but I suggest you give it another try unless you're absolutely sure.
Also Webpack does not depend on chokidar itself, its new default watching plugin does. It's entirely possible to plug another watcher implementation, but have exactly the same infrastructure for hot updates, etc.
By the way, I'm sorry if this is something you don't plan to consider, I totally understand that.
I'm just saying it's a shame we'll have a different "push code updates" system on React Native because, if it is implemented, I expect it to only support "refresh" signals, whereas an existing Webpack solution supports Hot Module Replacement. Hot Module Replacement is vastly superior to a "refresh" signal system but supports it as a degraded simple case, so it's usable from day one.
Many React developers consider hot replacement useful. It's not trivial to implement, so if we're not reusing Webpack's HMR runtime, we likely won't get it soon..
Reacted by Michael JacksonI think we want to be flexible enough for users to make their own choices and maybe support some of the popular things out of the box. I'm on mobile now but I'll reply later with some of the constraints we had when building this and why we couldn't pick one of the ready made solutions.
Thank you, appreciated!
It would be awesome if you exposed a way to reload a page and a way to "inject a script" to JS side. Then we'd be able to use any server and any (hot or not) reloading solution.. I think.
In addition to having a proprietary module format, and because we have a large codebase and needed to use watchman for high performance and more reliable file watching, performance was a big concern. We needed the compiler to work in parallel and we even hand optimized source map generation so we can give error stacks on the client with correct line numbers. Maybe everything can be written as a plugin to webpack but at what point you're reimplementing the program you're supposed to be plugging into. Finally, our vision to what our server should be doing is beyond packaging. We want to integrate Jest testing, Flow type checking, code optimization (dead code elimination, inlining etc).
That shouldn't mean that external react-native users shouldn't or can't use webpack, or for that matter shouldn't replace any of the things I mentioned. You should be able to use Mocha instead of Jest, or 6to5 instead of jstransform etc.
Anyways things are still pretty much work in progress, and feedback like this helps. Thanks
I'm curious if you guys think it would help for us to provide support for webpack's loader and plugin API out of the box for our packaging system?
That would give us access to most of webpack's module ecosystem while still giving us flexibility to implement features that webpack may not be designed for - particularly features around testing, code intelligence, flow integration, etc.
I'm sure Webpack's plugin API would be very hard (it's very tied to how Webpack processes modules, down to compilation phases) so it's probably entirely out of the question.
Implementing Webpack loader support is easier, but only for trivial things like transforming files. It's a lot more work for complex loader features (pitching loaders, async transformers, marking dependencies, require.resolve, etc). RN packager could implement a subset of those, but it is not worth it in my opinion, as it would only cause fragmentation in Webpack ecosystem (is that particular loader supported by RN?) and I doubt RN team wants to be constrained by Webpack APIs.
A more sustainable alternative, in my opinion, is to let users choose a bundler, and add whatever polyfills/bridges we may need for Webpack to work with RN:
WebSocketAPI or equivalent- An equivalent of
window.reload() - An equivalent of loading
<script>tag dynamically
I really wish @sokra was with us in this discussion!
11 remaining items
@amasad I used the easter holydays to implement new SourceMaps for webpack.
devtool: "cheap-inline-source-map"should be much faster (ordevtool: "cheap-module-inline-source-map"if you want source mappings to jsx). Still experimental, but you can try it.http://webpack.github.io/docs/configuration.html#devtool
It uses a similar approach as react-native: it only maps lines and avoids recomputing base64vlc numbers.
Thanks @sokra! 👍👍👍
We are not yet able to process all
react-nativeproject files withwebpackbecause MessageQueue module uses dynamic require in a way not supported bywebpackat the moment. The fact that allreact-nativemodules internally use flattened module names (ex:require('ModuleName')) makes it even trickier (or impossible) to hack withContextReplacementPlugin. A hybrid approach (usingreact-native's packagerfornode_modules/react-native/**/*andwebpackfor the rest) is one way to usewebpackbut we cannot test the newcheap-inline-source-mapdevtool option with that approach becausepackageronly cares about the code, not the source map.I believe we need more powerful way to handle dynamic requires in
webpackthat works with aliased module names in order to process all files withwebpackunlessreact-nativechanges its code to supportwebpack.The way we currently communicate for Obj-C to JavaScript is by doing
eval('require("ModuleName").methodName(arguments)');. Fortunately, most of it is abstracted away in only 7 methods. What we need to do is to change the call toeval('ReactNativeJSExposedMethods.call('ModuleName', 'MethodName', arguments)')and have all those methods register themselves before being called.RCTEventEmitter.receiveTouches RCTNativeAppEventEmitter.emit RCTEventEmitter.receiveEvent ReactIOS.unmountComponentAtNodeAndRemoveContainer AppRegistry.runApplication RCTJSTimers.callTimers RCTDeviceEventEmitter.emitThis is on my todo list but I'm unlikely going to be able to get to it this week if someone wants to pick it up
- added a commit that references this issue
on Jul 6, 2016 - added a commit that references this issue
on Sep 13, 2016 - added a commit that references this issue
on Nov 7, 2017 - added a commit that references this issue
on Nov 19, 2017 - added a commit that references this issue
on Jan 4, 2018 - locked as resolved and limited conversation to collaborators
on May 29, 2018 - added a commit that references this issue
on Sep 24, 2021
Is it possible to have the simulator automatically refresh when a file is changed instead of Cmd-R?