This is a big PR that will probably precipitate a lot more structural shifts towards an architecture more rooted in current best practices for web dev.
Pros:
Fractive devs can now install any browserify-compatible npm module locally in their stories and access them at runtime using require().
We can now reference node modules inside Core at runtime, which opens up a lot of possibilities for expanding the library without bloating our own codebase with cruft we'll have to maintain later.
Cons
Variables and functions referenced through Markdown now need to be declared in Javascript more strictly, i.e. window.globalVar instead of var globalVar or globalVar, and functions must be declared as window.Function = function() in order for globals to be accessible to Core. I will argue this is worth the cost because var declarations are meant to be local, not global, and previously we weren't respecting this. Also, assignment to undeclared variables (i.e. the creation of implicit globals) is considered by some to be bad practice and under use strict syntax, forbidden. So this change merely enforces what would be thought of best practices for JavaScript, and prevents unintended global variable errors.
So I can see why this might go against some of the design principles you set out with, but so far it's working well for me and it will be the basis for a lot of my future enhancements to SpaceFractive, so I'd hope it can be accepted and I'll be able to keep contributing back to the upstream.
This is a big PR that will probably precipitate a lot more structural shifts towards an architecture more rooted in current best practices for web dev.
Pros:
require()
.Core
at runtime, which opens up a lot of possibilities for expanding the library without bloating our own codebase with cruft we'll have to maintain later.Cons
window.globalVar
instead ofvar globalVar
orglobalVar
, and functions must be declared aswindow.Function = function()
in order for globals to be accessible to Core. I will argue this is worth the cost because var declarations are meant to be local, not global, and previously we weren't respecting this. Also, assignment to undeclared variables (i.e. the creation of implicit globals) is considered by some to be bad practice and underuse strict
syntax, forbidden. So this change merely enforces what would be thought of best practices for JavaScript, and prevents unintended global variable errors.So I can see why this might go against some of the design principles you set out with, but so far it's working well for me and it will be the basis for a lot of my future enhancements to SpaceFractive, so I'd hope it can be accepted and I'll be able to keep contributing back to the upstream.
@invicticide to review