neo.mjs 6.15.5 → 6.15.6

package/docs/tutorials/01_Concept.json

@@ -1,123 +0,0 @@
-[
-    {
-        "tag": "div",
-        "cls": ["neo-header-text-container"],
-        "cn" : [
-            {
-                "tag"      : "span",
-                "cls"      : ["neo-header-text"],
-                "innerHTML": "Tutorial: Concept"
-            }
-        ]
-    },
-    {
-        "tag": "article",
-        "cn" : [
-            {
-                "tag"      : "h4",
-                "innerHTML": "Why yet another Javascript framework?"
-            },
-            {
-                "tag": "ol",
-                "cn" : [
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "neo.mjs is web workers driven"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "neo.mjs does not need any cryptic XML markups"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "neo.mjs uses a custom blazing fast virtual dom engine"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "neo.mjs is based on EcmaScript 8 (ES8)"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "neo.mjs uses HTML5 and CSS3 to the fullest"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "Simplicity"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "No transpiled code"
-                    }
-                ]
-            },
-            {
-                "tag": "hr"
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(1) neo.mjs uses 3 web workers:"
-            },
-            {
-                "tag": "ul",
-                "cn": [
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "App"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "Data"
-                    },
-                    {
-                        "tag"      : "li",
-                        "innerHTML": "Vdom"
-                    }
-                ]
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "The main reason is that browsers by default only use 1 CPU core, while most computers and mobile devices have more. Multi-Threading solves this performance bottleneck and it will ensure that there are no hidden background-tasks in the main thread, which mess with your beautiful animations."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "In short: Most parts of neo.mjs as well as all apps you will create are inside the App worker."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "The main thread is only responsible to manipulate the DOM and delegate DOM events to the App worker."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "The Data worker will perform all Ajax requests to your backend and host the Store instances."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "The Vdom worker parses your JSON based markup (Vdom) into a virtual node (Vnode) and creates deltas when you dynamically change your Vdom."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(2) Did you ever enjoy writing pseudo-html including curly braces like {tpl if}, {tpl for} or even better {[this.doSomething()]}? Those XML templates evolved to a point, where they try to do everything what Javascript itself is capable of and you will most likely have encountered scoping issues (where does "this" point to now?). The solution is as simple as it should have been obvious for quite a while: JSON. You can easily manipulate Javascript objects with Javascript."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(3) Since neo.mjs does not need to parse XML templates back into JSON and then create virtual DOM nodes, the custom Vdom engine is blazing fast. The algorithms to create deltas are highly efficient and recognise moved DOM subtrees immediately."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(4) neo.mjs is most likely the first UI framework out there which does not only allow devs to create ES8 classes on top of ES5 prototypes, but is itself fully written in ES8."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(5) neo.mjs uses the latest web APIs and CSS features to the fullest and give you an easy and intuitive access to them."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(6) The first and most important design goal of neo.mjs is simplicity. This does not only mean to keep the code base as clean and simple as possible, but also to keep the created DOM as lightweight and minimal as possible."
-            },
-            {
-                "tag"      : "p",
-                "innerHTML": "(7) neo.mjs does not use Babel or any other tool to transpile code (which does not mean you can't use it for your own apps)."
-            }
-        ]
-    }
-]

package/docs/tutorials/01_Concept.md

@@ -1,55 +0,0 @@
-#### Why yet another Javascript framework?
-
-1. neo.mjs is web workers driven
-2. neo.mjs does not need any cryptic XML markups
-3. neo.mjs uses a custom blazing fast virtual dom engine
-4. neo.mjs is based on EcmaScript 8 (ES8)
-5. neo.mjs uses HTML5 and CSS3 to the fullest
-6. Simplicity
-7. No transpiled code
-
-____
-
-(1) neo.mjs uses 3 web workers:
-* App
-* Data
-* Vdom
-
-The main reason is that browsers by default only use 1 CPU core, while most computers and mobile devices have
-more. Multi-Threading solves this performance bottleneck and it will ensure that there are no hidden
-background-tasks in the main thread, which mess with your beautiful animations.
-
-In short: Most parts of neo.mjs as well as all apps you will create are inside the App worker.
-
-The main thread is only responsible to manipulate the DOM and delegate DOM events to the App worker.
-
-The Data worker will perform all Ajax requests to your backend and host the Store instances.
-
-The Vdom worker parses your JSON based markup (Vdom) into a virtual node (Vnode) and creates deltas
-when you dynamically change your Vdom.
-
-
-(2) Did you ever enjoy writing pseudo-html including curly braces like {tpl if}, {tpl for} or even better
-{[this.doSomething()]}? Those XML templates evolved to a point, where they try to do everything what
-Javascript itself is capable of and you will most likely have encountered scoping issues (where does "this"
-point to now?). The solution is as simple as it should have been obvious for quite a while: JSON. You can easily manipulate Javascript objects with Javascript.
-
-
-(3) Since neo.mjs does not need to parse XML templates back into JSON and then create virtual DOM nodes,
-the custom Vdom engine is blazing fast. The algorithms to create deltas are highly efficient and
-recognise moved DOM subtrees immediately.
-
-
-(4) neo.mjs is most likely the first UI framework out there which does not only allow devs to create
-ES6 classes on top of ES5 prototypes, but is itself fully written in ES6.
-
-
-(5) neo.mjs uses the latest web APIs and CSS features to the fullest and give you an easy and intuitive
-access to them.
-
-
-(6) The first and most important design goal of neo.mjs is simplicity. This does not only mean to keep the
-code base as clean and simple as possible, but also to keep the created DOM as lightweight and minimal as
-possible.
-
-(7) neo.mjs does not use Babel or any other tool to transpile code (which does not mean you can't use it for your own apps).

package/docs/tutorials/02_ClassSystem.html

@@ -1,171 +0,0 @@
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Tutorial: Class System</span>
-</div>
-<article>
-    <ol>
-        <li>Flaws of the ES6+ class system
-            <ol>
-                <li>No &quot;this&quot; inside constructors before the parent call</li>
-                <li>It is not possible to define properties inside the class body without using get &amp; set</li>
-                <li>No private methods or properties</li>
-                <li>No support for mixins</li>
-            </ol>
-        </li>
-        <li>Neo Modules &amp; Classes
-            <ol>
-                <li>One Class per File</li>
-                <li>Each Class is &quot;wrapped&quot; inside a JS Module</li>
-                <li>Private Class methods</li>
-                <li>*.mjs</li>
-            </ol>
-        </li>
-        <li>Neo ES6+ Class Enhancements
-            <ol>
-                <li>Neo.applyClassConfig</li>
-                <li>Reducing boiler plate code</li>
-            </ol>
-        </li>
-    </ol>
-    <h4>(1) Flaws of the ES6+ class system</h4>
-    <p>(1.1.) This might not sound like a big deal at first, but it does prevent any pre-processing inside the
-        constructor chain.</p>
-    <pre><code>class TabContainer extends Container {
-    construct(config) {
-        //let me = this; // breaks!
-        super.construct(config);
-        let me = this;  //ok
-    }
-}</code></pre>
-    <p>(1.2.) The most likely biggest flaw is that you can not define any properties directly inside the class body,
-        as well as a missing config system.</p>
-    <pre><code>class TabContainer extends Container {
-    activeIndex: 1 // nope
-    static foo: 'bar' // impossible as well
-}</code></pre>
-    <p>There is hope: <a target="_blank" href="https://tc39.github.io/proposal-class-fields/#sec-private-bound-names">https://tc39.github.io/proposal-class-fields/#sec-private-bound-names</a>
-    </p>
-    <p>(1.3.) Although there are some proposals out there for many years, still not implemented.</p>
-    <p>(1.4.) Independant whether you like the mixin pattern or not, it is just not possible.</p>
-    <hr>
-    <h4>(2) Neo Modules &amp; Classes</h4>
-    <p>(2.1.) One Class per File. Might sound trivial from classic OOP concepts, but we do stick to it and recommend you
-        to
-        do the same for your application files.</p>
-    <p>(2.2) As soon as you want to extend an ES6+ class, you need to ensure that the base class is available.
-        One good way to achieve this is to use import:</p>
-    <p><a target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import</a>
-    </p>
-    <p>This automatially makes the file a JS module and you will notice that we will at least export the Class
-        at the end of of each module.</p>
-    <p>(2.3) Having the JS Module around each Class definition allows us to place methods outside of the class
-        deinition,
-        but still between the import and export statements. A nice place for &quot;private&quot; methods or attributes
-        which can get
-        accessed from Class methods easily, but not as easy from the outside world.</p>
-    <p>(2.4.) In case you missed it, *.mjs is not something we came up with, but the new standard file extension name
-        for
-        Javascript Modules. You can find more details e.g. in Axels Blog:</p>
-    <p>
-        <a target="_blank" href="http://2ality.com/2017/05/es-module-specifiers.html">http://2ality.com/2017/05/es-module-specifiers.html</a>
-    </p>
-    <hr>
-    <h4>(3) Neo ES6+ Class Enhancements</h4>
-    <p>(3.1.) To reduce the issue of 1.2. we created Neo.applyClassConfig (Neo.mjs),
-        which does get called in every Class File at the very bottom (before the export statement).
-        If you look at Neo Class / Module files, like component/Button.mjs, you will notice 2 methods at the top of the
-        class body:</p>
-    <h5>getStaticConfig</h5><h5>getConfig</h5>
-    <p>Both methods simply return an object. Put all static keys into getStaticConfig and all other ones into getConfig.
-        Neo.applyClassConfig <strong>(strongly recommended to look at the source code)</strong> will apply all static
-        configs to the class
-        constructor (as well as adding the staticConfig object itself there) and all non static configs will get added
-        using
-        Object.defineProperty() on the Class prototype.</p>
-    <p>So, why is a &quot;config system&quot; useful, you might ask yourself at this point.
-        This can easily get showcased using a simple example:</p>
-    <pre><code>class TabContainer extends Container {
-    get activeIndex() {
-        return this._activeIndex || 0;
-    }
-    set activeIndex(value) {
-        this._activeIndex = value;
-    }
-}</code></pre>
-    <p>So far so good, we now have an activeIndex property which will use _activeIndex to read &amp; save its value.
-        Now you might want to extend this class:</p>
-    <pre><code>class MyTabContainer extends TabContainer {
-    static getConfig() {return {
-        _activeIndex: 1
-    }}
-}</code></pre>
-    <p>Ok, this one was easy. _activeIndex will get applied as a class property.
-        Neither the first version with 0 nor the second one using the underscore and the value of 1 will trigger the
-        setter.
-        When you call:</p>
-    <pre><code>Neo.create(MyTabContainer);</code></pre>
-    <p>the constructor of our Base Class (Neo.core.Base) will call initConfig(),
-        which will apply _activeIndex to the instance, silently setting the value</p>
-    <pre><code>class MyTabContainer2 extends TabContainer {
-    static getConfig() {return {
-        activeIndex: 1
-    }}
-}</code></pre>
-    <p>Now it does get more interesting. You want to trigger the setter when creating an instance,
-        but you definitely do <strong>not</strong> want to override the activeIndex property defined via get &amp; set
-        with the new one.
-        No worries, Neo.applyClassConfig will check the base class prototype chain and in case it does find a property
-        with the
-        same name, it will not override the version having the setter. Instead it will only apply activeIndex inside the
-        config
-        object itself.
-        Now, when you call:</p>
-    <pre><code>Neo.create(MyTabContainer2);</code></pre>
-    <p>the constructor of our Base Class (Neo.core.Base) will call initConfig(),
-        which will apply activeIndex to your instance and this will call the setter.</p>
-    <pre><code>Neo.create(MyTabContainer2, {
-    activeIndex: 2
-});</code></pre>
-    <p>This will also call the setter <strong>once</strong>, this time using the value of 2
-        (initConfig does merge the prototype config object with the one you pass into Neo.create -&gt; the constructor)
-    </p>
-    <p>(3.2.) Reducing boiler plate code. When looking back at the first TabContainer example you will probably think:
-        Damn, in case I want to define many properties via get&amp;set which all just save&amp;get their value inside an
-        undercored
-        version of its name key, this will create quite some overhead.</p>
-    <p>To avoid this and make your code more beautiful, we added a trailing underscore for class configs:</p>
-    <pre><code>class TabContainer extends Container {
-    static getConfig() {return {
-        activeIndex_: 0
-    }}
-}</code></pre>
-    <p>Look close: activeIndex<span style="color:red;font-size:200%;">_</span> .This gets you the exact same result as
-        the previous example:</p>
-    <pre><code>class TabContainer extends Container {
-    get activeIndex() {
-        return this._activeIndex || 0;
-    }
-    set activeIndex(value) {
-        this._activeIndex = value;
-    }
-}</code></pre>
-    <p>Even better, this also <strong>optionally</strong> gives you support for 3 more methods you can use:</p>
-    <pre><code>class TabContainer extends Container {
-    static getConfig() {return {
-        activeIndex_: 0
-    }}
-
-    beforeSetActiveIndex(value, oldValue) {
-        return 42; // the answer to Life, the Universe, and Everything
-    }
-
-    beforeGetActiveIndex(value) {
-        return 5; // but hey, why tell anyone?
-    }
-
-    // this one would only get called in case value !== oldValue
-    afterSetActiveIndex(value, oldValue) {
-        // update the UI
-    }
-}</code></pre>
-    <p><a href="module-Neo.html#~autoGenerateGetSet">Details here</a></p>
-</article>

package/docs/tutorials/02_ClassSystem.md

@@ -1,187 +0,0 @@
-1. Flaws of the ES6 class system
-    1. No "this" inside constructors before the parent call
-    2. It is not possible to define properties inside the class body without using get & set
-    3. No private methods or properties
-    4. No support for mixins
-2. Neo Modules & Classes
-    1. One Class per File
-    2. Each Class is "wrapped" inside a JS Module
-    3. Private Class methods
-    4. *.mjs
-3. Neo ES6 Class Enhancements
-    1. Neo.applyClassConfig
-    2. Reducing boiler plate code
-
-#### (1) Flaws of the ES6 class system
-
-(1.1.) This might not sound like a big deal at first, but it does prevent any pre-processing inside the constructor chain.
-```
-class TabContainer extends Container {
-    construct(config) {
-        //let me = this; // breaks!
-        super.construct(config);
-        let me = this;  //ok
-    }
-}
-```
-
-(1.2.) The most likely biggest flaw is that you can not define any properties directly inside the class body,
-as well as a missing config system.
-```
-class TabContainer extends Container {
-    activeIndex: 1 // nope
-    static foo: 'bar' // impossible as well
-}
-```
-There is hope: <https://tc39.github.io/proposal-class-fields/#sec-private-bound-names>
-
-(1.3.) Although there are some proposals out there for many years, still not implemented.
-
-(1.4.) Independant whether you like the mixin pattern or not, it is just not possible.
-
-- - - -
-
-#### (2) Neo Modules & Classes
-
-(2.1.) One Class per File. Might sound trivial from classic OOP concepts, but we do stick to it and recommend you to
-do the same for your application files.
-
-(2.2) As soon as you want to extend an ES6 class, you need to ensure that the base class is available.
-One good way to achieve this is to use import:
-
-<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import>
-
-This automatially makes the file a JS module and you will notice that we will at least export the Class
-at the end of of each module.
-
-(2.3) Having the JS Module around each Class definition allows us to place methods outside of the class deinition,
-but still between the import and export statements. A nice place for "private" methods or attributes which can get
-accessed from Class methods easily, but not as easy from the outside world.
-
-(2.4.) In case you missed it, *.mjs is not something we came up with, but the new standard file extension name for 
-Javascript Modules. You can find more details e.g. in Axels Blog:
-
-<http://2ality.com/2017/05/es-module-specifiers.html>
-
-- - - -
-
-#### (3) Neo ES6 Class Enhancements
-
-(3.1.) To reduce the issue of 1.2. we created Neo.applyClassConfig (Neo.mjs),
-which does get called in every Class File at the very bottom (before the export statement).
-If you look at Neo Class / Module files, like component/Button.mjs, you will notice 2 methods at the top of the class body:
-
-##### getStaticConfig
-
-##### getConfig
-
-Both methods simply return an object. Put all static keys into getStaticConfig and all other ones into getConfig.
-Neo.applyClassConfig **(strongly recommended to look at the source code)** will apply all static configs to the class
-constructor (as well as adding the staticConfig object itself there) and all non static configs will get added using
-Object.defineProperty() on the Class prototype.
-
-So, why is a "config system" useful, you might ask yourself at this point.
-This can easily get showcased using a simple example:
-
-```
-class TabContainer extends Container {
-    get activeIndex() {
-        return this._activeIndex || 0;
-    }
-    set activeIndex(value) {
-        this._activeIndex = value;
-    }
-}
-```
-So far so good, we now have an activeIndex property which will use _activeIndex to read & save its value.
-Now you might want to extend this class:
-```
-class MyTabContainer extends TabContainer {
-    static getConfig() {return {
-        _activeIndex: 1
-    }}
-}
-```
-Ok, this one was easy. _activeIndex will get applied as a class property.
-Neither the first version with 0 nor the second one using the underscore and the value of 1 will trigger the setter.
-When you call:
-```
-Neo.create(MyTabContainer);
-```
-the constructor of our Base Class (Neo.core.Base) will call initConfig(),
-which will apply _activeIndex to the instance, silently setting the value
-
-```
-class MyTabContainer2 extends TabContainer {
-    static getConfig() {return {
-        activeIndex: 1
-    }}
-}
-```
-Now it does get more interesting. You want to trigger the setter when creating an instance,
-but you definitely do **not** want to override the activeIndex property defined via get & set with the new one.
-No worries, Neo.applyClassConfig will check the base class prototype chain and in case it does find a property with the
-same name, it will not override the version having the setter. Instead it will only apply activeIndex inside the config
-object itself.
-Now, when you call:
-```
-Neo.create(MyTabContainer2);
-```
-the constructor of our Base Class (Neo.core.Base) will call initConfig(),
-which will apply activeIndex to your instance and this will call the setter.
-```
-Neo.create(MyTabContainer2, {
-    activeIndex: 2
-});
-```
-This will also call the setter **once**, this time using the value of 2
-(initConfig does merge the prototype config object with the one you pass into Neo.create -> the constructor)
-
-(3.2.) Reducing boiler plate code. When looking back at the first TabContainer example you will probably think:
-Damn, in case I want to define many properties via get&set which all just save&get their value inside an undercored
-version of its name key, this will create quite some overhead.
-
-To avoid this and make your code more beautiful, we added a trailing underscore for class configs:
-```
-class TabContainer extends Container {
-    static getConfig() {return {
-        activeIndex_: 0
-    }}
-}
-```
-Look close: activeIndex<span style="color:red;font-size:200%;">_</span> .This gets you the exact same result as the previous example:
-```
-class TabContainer extends Container {
-    get activeIndex() {
-        return this._activeIndex || 0;
-    }
-    set activeIndex(value) {
-        this._activeIndex = value;
-    }
-}
-```
-Even better, this also **optionally** gives you support for 3 more methods you can use:
-```
-class TabContainer extends Container {
-    static getConfig() {return {
-        activeIndex_: 0
-    }}
-    
-    beforeSetActiveIndex(value, oldValue) {
-        return 42; // the answer to Life, the Universe, and Everything
-    }
-    
-    beforeGetActiveIndex(value) {
-        return 5; // but hey, why tell anyone?
-    }
-    
-    // this one would only get called in case value !== oldValue
-    afterSetActiveIndex(value, oldValue) {
-        // update the UI
-    }
-}
-```
-<a href="module-Neo.html#~autoGenerateGetSet">Details here</a>
-
-
-

package/docs/tutorials/03_ComponentLifecycle.html

@@ -1,28 +0,0 @@
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Tutorial: Component Lifecycle</span>
-</div>
-<article>
-    <ol>
-        <li>constructor</li>
-        <li>onConstructed</li>
-        <li>init</li>
-        <li>render</li>
-        <li>mount</li>
-        <li>addDomListeners</li>
-        <li>destroy [optional]</li>
-    </ol>
-    <p>(1) Since constructors of ES6 classes may not use &quot;this&quot; before the parent call, this one does very
-        little,
-        except registering the new Component to the Component Manager.</p>
-    <p>(2) onConstructed gets called after the constructor chain is done and basically the replacement for the
-        constructor logic.</p>
-    <p>(3) init gets called after the onConstructed chain is done and will call render in case the autoRender-config is
-        set to true.</p>
-    <p>(4) render will call the Vdom worker sending the vdom (markup) and getting a vnode back.
-        Instances with children (e.g. Container -&gt; items) will delegate the sub-trees (vnodes) downwards.</p>
-    <p>(5) mount will send the full vnode-tree of your app (containing the outerHTML) to the main thread and create the
-        real DOM.</p>
-    <p>(6) Since the vdom &amp; vnode should not be aware of any DOM listeners, applying DOM listeners to the real DOM
-        happens after mount.</p>
-    <p>(7) Destroying a Component will unregister it from the Component Manager &amp; clear the listener references</p>
-</article>

package/docs/tutorials/03_ComponentLifecycle.md

@@ -1,23 +0,0 @@
-1. constructor
-2. onConstructed
-3. init
-4. render
-5. mount
-6. addDomListeners
-7. destroy [optional]
-
-(1) Since constructors of ES6 classes may not use "this" before the parent call, this one does very little,
-except registering the new Component to the Component Manager.
-
-(2) onConstructed gets called after the constructor chain is done and basically the replacement for the constructor logic.
-
-(3) init gets called after the onConstructed chain is done and will call render in case the autoRender-config is set to true.
-
-(4) render will call the Vdom worker sending the vdom (markup) and getting a vnode back.
-Instances with children (e.g. Container -> items) will delegate the sub-trees (vnodes) downwards.
-
-(5) mount will send the full vnode-tree of your app (containing the outerHTML) to the main thread and create the real DOM.
-
-(6) Since the vdom & vnode should not be aware of any DOM listeners, applying DOM listeners to the real DOM happens after mount.
-
-(7) Destroying a Component will unregister it from the Component Manager & clear the listener references