hasharray / liveflow.js Goto Github PK

Live Editing for Node.js and Browsers

Makefile 3.04% HTML 18.71% JavaScript 78.25%

liveflow.js's Introduction

Liveflow.js - Live Editing for Node.js and Browsers

Liveflow.js is a small runtime extension that enables live-editing of scripts as-well as live-reloading of required json files.

It's a pure, self-contained JavaScript based implementation with no external parts and should work in any more or less any JavaScript runtime, be it Node.js, Chrome, Firefox, Safari, Internet Explorer or Microsoft Edge.

Features

Live Editing of Scripts

Whenever scripts are changed on disk, across the network or within the document object model itself (e.g inline script tags) the source of that script is re-evaluated in its original execution context.

Re-evaluation means the following things:

Modified and new top level call expressions are called.
Surviving call expressions yield their previous value.
Function modifications are applied.

Live Reloading of Documents

Whenever a document is changed on disk or across the network, the page will be reloaded.

Live Reloading of Style Sheets

Whenever style-sheets are changed on disk or across the network, the old style link will be replaced with a new one causing the style-sheet to reload.

Live Reloading of Images

Whenever image sources are changed on disk or across the network, the image elements linking to that file will be reloaded.

Live Reloading of JSON

Whenever the source of a JSON file changes on disk that has been imported with require, it will reload and replace the key/value pairs on the original object.

This only applies to Node.js environments.

Getting Started

Liveflow.js has been designed to be as configuration free as possible, just include the script in your runtime environment and be done with it.

Node.js

Install the liveflow module.

npm install liveflow

Start node with the --require (shorthand -r) option, passing in liveflow as the module name to require.

node -r liveflow myapp.js

Enjoy live editing and reloading.

Browser

Include the following script at the very top of the head section in your document, it should be the first element after the opening <head> tag.

<script src="//liveflow.js.org/liveflow.js"></script>

Open the document in your preferred browser.
Enjoy live editing and reloading.

Documentation

See https://liveflow.js.org.

License

MIT

liveflow.js's People

Contributors

Stargazers

Watchers

Forkers

frugality red78massive1573

liveflow.js's Issues

New scripts added to documents do not execute

Hi ,

I have tried demo https://thingamajig.js.org/ but code withing anonymus function / withing document ready block did not work.

(function() {
document.querySelector('span').innerHTML = "aaaaaaaaaaaaaaa";
})();

Integration testing

The parts that make up thingamajig, are all unit tested here, we do still need to to some integration testing however to check that the hooks work as intended and don't regress.

Write user documentation

Documentation wise, there is not much to it beyond "load the extension" but it can still be well documented.

Detail every step
Detail every detail
Make no assumptions at all (e.g, "just start it with --require option, is bad and not explicit enough)
Pictures is okay, thingamajig is basically an extension, even when running as a site script.

Partial document reloading

Instead of reloading the entire document, we should try to figure out if any parts of it can be patched.

WHATWG Loader

The WHATWG Loader is so much in flux right now that I wont implement it for 1.0, latest proposals on the https://github.com/whatwg/loader repo is to remove the entire System namespace and just use import as a function.

Use <plaintext> to preprocess the document

Currently I'm trying to emulate beforescriptexecute with some hackery of calling window.stop, which leads to a bunch of problems cross-browser issues as stop doesn't behave the same in gecko and webkit.

Earlier on I was using <template> tags to render the document inert, but those translate into document fragments which eat up <head> and <body>.

What we actually want here, is to switch the tokenizer into a raw form, so we can just preprocess the document content before doing another document.write.

Reading through the 5.1 specification, <plaintext> is very clearly there, and even better is this part

Once a start tag with the tag name "plaintext" has been seen, that will be the last token ever seen other than character tokens (and the end-of-file token), because there is no way to switch out of the PLAINTEXT state.

Acciental page destruction

Not sure what went down, but gh-pages have been wiped during deployment.

Preprocessors

Currently, no 'browser based' preprocessors are supported, it's fairly trivial to add but I'm not sure If i want to, or even should do it.

By browser based preprocessors I mean scripts that have a custom type like text/babel

<script type="text/babel">
// ...
</script>

Its beneficial for demo page(s), but thats about it as normally one would be better off doing babel --watch or the equivalent.

Supposed to work?

Bumped into this project, which looks really cool. But...

it seems unclear how this relates to thingamajig and amok. Are those old repos for the same code? Want to clarify
it seems the npm package doesn't contain any code
loading the liveflowjs over network just yields

Uncaught DOMException: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'http://liveflow.js.org/liveflow.js'.

...so am I missing something?

Optimize browser builds

Browser builds are a bit 'large' (only 50kb) but still carries some dead weight.

Unable to instrument code contain in document.ready

Hi , you help me on this stackoverflow question
http://stackoverflow.com/questions/40375167/how-can-i-intercept-js-code-before-exectution-in-chrome

I am facing problem if orignal code contains inside document ready or $(function () { alert("test"); }); Then it does not execute after instrumentation. Even if my instrumentation return orignal code. And idea to resolve that ?

Support native modules

Still, a guessing game how ES6 modules will work in practice (loader wise, syntax semantics are well understood) but Edge does have support for native imports now so there is AN implementation to look at.

Support stylesheet reloading

Consider using `beforescriptexecute`

Was not aware, randomly came across it now on MDN but there IS actually a hook in Firefox and Opera that is executed before a script is executed.

Should be able to implement a polyfill for it using the current approach of halting the page, the firefox implementation does what we need (event.preventDefault stops a script from loading).

Configurable interval and include/exclude patterns

Need some way to include/exclude scripts and files from being included, cdn scripts for example makes sense to just leave alone, by definition they cannot change.

Add user-defined watch callbacks

Expose a function called watch, this function will register a callback which is called once the file has been processed.

watch('myfile.js', function() {
  console.log('myfile.js has been reloaded');
});

It should accept patterns

watch(/\.js$/, function() {
  React.render(/* ... */);
});

And if the file is not currently being watched, a file watcher should be installed for user-space consumption.

E.g, imagine reloading textures in a rendering API.

if (typeof watch != 'undefined') {
  watch(/\.(png|jpeg)$/, function(pathname) {
   if (!display.hasTexture(pathname)) {
     return;
   }

    display.createTexture('tex.png', function(texture) {
      console.log('reloaded that texture');
    });
  });
}

Support image reloading

Browser extension(s)

Add a web extension injecting injecting the browser script.

Optional browser socket

Might be worth supporting a socket protocol, or at the very least keep-alive HEAD requests to reduce the polling noise as every server in existence will log out the HEAD requests thingamajig makes.

The network tab also gets a bit, noisy.

I won't drop polling support, as it does the job without requiring any server setup or configuration, but it could be a fallback.

Asynchronously doing synchronous document write's

Writing cross origin scripts leads to potential blocking from Chrome, to get around this split the document up in chunks, and wait for script onload before continuing with further writes.

This also lets us do asynchronous XHR requests, so those warnings can be a thing of the past as-well with this change.

UMD scripts not exporting

jQuery, React etc from cdnjs are not currently exporting to the window object while being evaluated, most likely this is revaluate failing to deal with UMD modules.