![]() ![]() If we want to eventually reintroduce a CDT connection (or hook up to RemoteDebug), we have two choices: we could either just implement it as a separate transport, or we could implement it as a separate protocol impl entirely. The over-the-wire protocol is a JSON message that more or less looks like the CDT wire protocol, although it's not an exact match right now - again, we could decide to make it exactly mimic CDT if we wanted. * "navigate" which allow the browser navigate to a given URL * "reload" which reload the page in the browser The protocol layer currently exposes a very simple API that currently just contains specific protocol functions: However, this could easily be swapped out for a different transport layer that supports a preview iframe directly inside Brackets, where the communication is via postMessage(). The transport layer currently implemented uses a WebSocket server in Node, coupled with an injected script in the browser that connects back to that server. The only reason to keep the protocol layer separate, IMO, is if we want to keep it compatible with CDT, a la RemoteDebug - so it only provides the functionality that CDT does.) (We could arguably get rid of the distinction between (2) and (3), and basically roll all the Brackets functionality into the "protocol" layer by simply merging the RemoteFunctions script into the protocol remote script. The reason for this factoring is so that the transport layer can be swapped out for different use cases, and so that anything higher-level we need that can be easily built in terms of eval doesn't have to be built into the protocol. the injected RemoteFunctions script, which is the same as in today's LiveDevelopment and provides Brackets-specific functionality (highlighting, DOM edit application) on top of the core protocol. ![]() ![]() the "protocol" layer, which sits on top of the transport layer and provides the actual semantic behavior (currently just "evaluate in browser").a low-level "transport" layer, which is responsible for launching live preview in the browser and providing a simple textual message bus between the browser and Brackets.opening dev tools in the browser doesn't break live previewĬommunication between Brackets and the browser is factored into three layers:.browsers could theoretically connect from anywhere on the network that can see Brackets (though right now it's only implemented for localhost).multiple browsers can connect to the same live preview session in Brackets.live preview can work in any browser, not just Chrome.launching a preview, injecting scripts into the HTML, and establishing the connection between the previewed page and Brackets are relatively simple and largely decoupled.The primary difference in this architecture is that communication with the browser is done via an injected script rather than CDT's native remote debugging interface, and the browser connects back to Brackets rather than Brackets connecting to the browser. Documents that are loaded by the current HTML live doc are being tracked by DocumentObserver at the browser side which relies on DOM MutationObserver for monitoring added/removed stylesheets and Javascript files (just monitoring and added/removed nodes so far. Page reload when saving changes on related Javascript files is also working. This is still an experimental implementation, the basic functionality for CSS/HTML editing is working but there are could be some scenarios that might be partially or entirely not covered yet. You should then also be able to copy and paste the URL from that browser into any other browser, live edits will then update all connected browsers at once. If enabled, it will launch will launch the page in your default browser when clicking on the LiveDevelopment icon as it works today. It can be enabled by setting livedev.multibrowser preference to true. It's based on the current Live Development code in Brackets and has been incubated at njx/brackets-livedev2. This is an experimental implementation to replace the current live development architecture with something more flexible that isn't tied solely to Chrome Developer Tools. Changes from existing LiveDevelopment code. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |