joewalnes
commented
8 years ago Musings...
The more I think about it, the more it makes sense to have the browser handle try to do as much as possible and to keep complexity out of the generated code.
How? For Chrome at least, it seems it's possible to use the debugging API to replace the contents a script live at runtime while the app is running. This is what happens when you edit code and hit save in the dev tools.
There are two options for controlling the debugger API:
- Use the Remote Debugging Protocol. Chrome has to be started with a cmd line flag and then a library like Chrome Remote Interface can be used to automate
- Or create a browser exension that uses the chrome.debugger APIs
My suspicion is:
- remote debugging will be easier to get something up and running with to build a proof of concept
- remote debugging will be a lousy end user experience (only one concurrent connection, disables browser dev tools, awkward cmd line setup and new user profile required, some known bugs with large file sizes)
- custom extension will require more dev work but will be a much simpler user experience (one time visit to chrome store to install extension)
To start with, I'll probably use remote debugging, but the extension will be the final goal.
Either way, it seems the relevant debug protocol hooks are:
- scriptParsed event: fired whenever JS script is loaded. This is where we'd keep track of the available scripts and their IDs.
- getScriptSource and setScriptSource commands: allows the underlying JS to be read/written.
Here's some examples I found that show how to update the JS live on a running page:
- https://gist.github.com/paulirish/920a260cadfe05e8388c
- https://github.com/mattdesl/budo-chrome/blob/69cd0bd7dcf8c5623d4f9dbe6e2c22cd92f9c33f/lib/remote-interface.js
- https://github.com/dmitry-vsl/chrome-reload-example/blob/master/server.js
- https://github.com/cabul/electron-hot/blob/master/lib/index.js
- https://github.com/caspervonb/bitty/blob/342961926e771e64f5e131f255593ab3195fa954/index.js#L172
- https://github.com/amokjs/amok/blob/master/lib/hotpatch.js#L108
In addition to updating the JS, a trigger must be sent to the page to tell it to do something (e.g. re-render react components).
This will require a bit of code to be added but it should be straight forward:
window.addEventListener('hotreload', render)Example triggering this remotely:
Accessing debugger from Chrome extension:
The goal of hot reloading is to allow code changes to propagate to the browser without forcing a refresh. This allows insanely fast feedback loops for UI changes.
This is a placeholder for a discussion on how to implement it.
One thing I don't want to do is force users to have to run a custom development server. This tightly couples users to Node based apps and doesn't support the needs of other server side web stacks (e.g. Rails, PHP, Go, Java, etc...).
Also, users should not have to write any additional code to get this to work. It should simply be a matter of
--hot.My preference is for hot loading to be provided by the browser developer tools, and should not require bundling additional code into a web-app. There may have to be a small out of band trigger that the cmd line tool can use to notify the browser that it should refresh the code and trigger a render.