neo.mjs 6.15.4 → 6.15.6

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

package/docs/tutorials/04_VdomVnode.html

@@ -1,161 +0,0 @@
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Tutorial: Virtual DOM & Virtual Nodes</span>
-</div>
-<article>
-    <h4>Virtual DOM (Vdom)</h4>
-    <p>Since most parts of the neoteric framework as well as all apps you will create run inside the App worker,
-    there is no direct access to the DOM (window & window.document are undefined inside the worker scope).</p>
-    <p>Neoteric uses a custom JSON / JS-Object based vdom engine to handle the component markup and the changes.
-    As an example, let's take a look at the component.Button markup:</p>
-    <pre><code>_vdom: {
-    tag: 'button',
-    cn : [{
-        tag: 'span',
-        cls: ['neo-button-glyph']
-    }, {
-        tag: 'span',
-        cls: ['neo-button-text']
-    }]
-}</code></pre>
-    <p>This template filled with content would create a resulting html like:</p>
-    <pre><code>&lt;button class="neo-button icon-left" id="neo-button-1000"&gt;
-    &lt;span class="neo-button-glyph fa fa-home" id="neo-vnode-1000">&lt;/span&gt;
-    &lt;span class="neo-button-text" id="neo-vnode-1001">Hello World&lt;/span&gt;
-&lt;/button&gt;</code></pre>
-    <p>Which will look like this:</p>
-    <button class="neo-button icon-left" id="neo-button-1000">
-        <span class="neo-button-glyph fa fa-home" id="neo-vnode-1000"></span>
-        <span class="neo-button-text" id="neo-vnode-1001">Hello World</span>
-    </button>
-    <p>Available properties for each vdom object are:</p>
-    <pre><code>{String}        tag|nodeName   the tag of the node, defaults to 'div'
-{String}        html|innerHTML node.innerHTML
-{Array}         cn             child nodes
-{Array|String}  cls            node.className
-{String}        flag           pseudo-attribute to find nodes via util.VDom.getByFlag() or util.VDom.getFlags()
-{Number|String} height         shortcut for style.height, defaults to px
-{String}        id             the dom id, will get auto-populated if not set (e.g. neo-vnode-1)
-{Number|String} maxHeight      shortcut for style.maxHeight, defaults to px
-{Number|String} maxWidth       shortcut for style.maxWidth, defaults to px
-{Number|String} minHeight      shortcut for style.minHeight, defaults to px
-{Number|String} minWidth       shortcut for style.minWidth, defaults to px
-{Object|String} style          camel cased style definitions
-{Boolean}       removeDom      pseudo-attribute to remove a node from the VNode tree
-{String}        vtype          'text' => inline text, positioned before or after nodes
-{Number|String} width          shortcut for style.width, defaults to px
-</code></pre>
-    <p>For more details, take a look at:
-        <a class="neo-docs-view-source-link" href="#viewSource=vdom.Helper&amp;line=223">vdom.Helper:parseHelper()</a>
-    </p>
-    <hr>
-    <h4>Rendering an app</h4>
-    <p>Once you created your app, you will call the render() method for its main view.
-        This will send the full vdom tree to the Vdom worker and create a Virtual Node (VNode) tree.<br>
-        See: <a class="neo-docs-view-source-link" href="#viewSource=component.Base&amp;line=769">component.Base:render()</a>
-    </p>
-    <p>The top level vnode will contain the full html as a string inside the outerHTML property.
-        If you want to, you could create an outerHTML property for each sub-node as well
-        (take a look at the vdom.Helper config returnChildNodeOuterHtml: false.
-        Not recommended or needed to change it, but it could help you for debugging purposes).
-    </p>
-    <hr>
-    <h4>Mounting an app</h4>
-    <p>Once you call mount() on your application main view (or in case the autoMount config is set to true),
-        the App worker will send the html to the main thread which will inject the html into a given DOM node id
-        or the framework will take care of the DOM node itself in case the main view is a container.Viewport.
-    </p>
-    <hr>
-    <h4>Virtual Nodes (Vnodes)</h4>
-    <p>After render() gets called on your main view, the framework will assign the relevant vnode sub-trees
-        to each container item in a recursive way. So at this point, every rendered component of your app will
-        have a vdom and a vnode property.
-    </p>
-    <hr>
-    <h4>Delta Updates</h4>
-    <p>After your app is mounted, you can modify the vdom of each component directly to trigger delta updates.
-        As an example:</p>
-    <pre><code>myButton.iconColor='red';</code></pre>
-    <p>This "assignment" will trigger the setter method of this config, which will call:</p>
-    <pre><code>afterSetIconColor(value) {
-    let me       = this,
-        vdom     = me.vdom,
-        iconNode = me.getVdomRoot().cn[0];
-
-    if (!iconNode.style) {
-        iconNode.style = {};
-    }
-
-    if (value && value !== '') {
-        iconNode.style.color = value;
-        me.vdom = vdom;
-    }
-}</code></pre>
-    <p>The result could look like this:</p>
-    <button class="neo-button icon-left" id="neo-button-1001">
-        <span style="color:red;" class="neo-button-glyph fa fa-home" id="neo-vnode-1002"></span>
-        <span class="neo-button-text" id="neo-vnode-1003">Hello World</span>
-    </button>
-    <p>The key here is me.vdom = vdom; which will trigger the vdom config setter, resulting in:
-    </p>
-    <pre><code>/**
- * Gets called after the vdom config gets changed in case the component is already mounted (delta updates).
- * @param {Object} vdom
- * @param {Neo.vdom.VNode} vnode
- * @private
- */
-updateVdom(vdom, vnode) {
-    let me = this;
-
-    Neo.vdom.Helper.update({
-        vdom : vdom,
-        vnode: vnode
-    }).then(data => {
-        Object.keys(me.vnode).forEach(key => {
-            delete me.vnode[key];
-        });
-
-        Object.assign(me.vnode, data.vnode);
-
-        me.syncVdomIds(me.vnode, me.vdom);
-    }).catch(err => {
-        console.log('Error attempting to update component dom', err, me);
-    });
-}</code></pre>
-    <p>The App worker will send the vdom & vnode property of this component to the VDom worker,
-        which will create a new vnode using the vdom and then compare the old & new vnodes to calculate the deltas,
-        which will modify the DOM as needed inside the main thread. Take a look at:<br>
-        <a class="neo-docs-view-source-link" href="#viewSource=vdom.Helper&amp;line=102">vdom.Helper:update()</a>
-    </p>
-    <p>The given example will create an deltas array like:</p>
-    <pre><code>deltas: [{
-    id: 'neo-button-1000',
-    style: {
-        color: 'red'
-    }
-}]</code></pre>
-    <p>The deltas will get sent to the main thread &
-        main.DomAccess:update() will apply each delta update to the real DOM automatically.</p>
-    <hr>
-    <h4>The virtual dom engine for delta updates is optional!</h4>
-    <p>In case you do know exactly what needs to change for a given component, you can also manually create the deltas
-        and send the result from the App worker to the main thread.
-        We do recommend to keep the vdom in sync though, since a top level component update could revert the manual changes
-        otherwise. One example for this strategy would be component.Helix:</p>
-    <pre><code>afterSetPerspective(value) {
-    let me = this;
-
-    if (me.mounted) {
-        Neo.currentWorker.promiseMessage('main', {
-            action: 'updateDom',
-            deltas: {
-                id   : me.vdom.id,
-                style: {
-                    perspective: value + 'px'
-                }
-            }
-        });
-
-        me.updateCloneTranslate();
-    }
-}</code></pre>
-</article>

package/docs/tutorials/05_RemoteMethodAccess.html

@@ -1,82 +0,0 @@
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Tutorial: Remote Method Access</span>
-</div>
-<article>
-    <p>To simplify the communication between the different workers (App, Data, VDom),
-        neoteric provides remote method access for singletons.
-        As an example, let's take a look at the vdom.Helper which lives inside the VDom worker:</p>
-    <pre><code>class Helper extends Base {
-    static getConfig() {return {
-        className: 'Neo.vdom.Helper',
-        ntype    : 'vdom-helper',
-        singleton: true,
-
-        remote: {
-            app: ['create', 'update']
-        }
-        //...
-    }
-
-    create(opts) {
-        //...
-    }
-
-    update(opts) {
-        //...
-    }
-
-    //...
-}</code></pre>
-    <p>As you can see, you can use the remote config to define method names (string based)
-        for other worker targets (lower case => app, data, vdom).
-        Using the remote config will automatically create the matching namespaces inside the target workers.
-        The remotely defined methods can then get called as a promise.
-        Example inside the App worker (component.Base):
-    </p>
-    <pre><code>updateVdom(vdom, vnode) {
-    let me = this;
-
-    Neo.vdom.Helper.update({
-        vdom : vdom,
-        vnode: vnode
-    }).then(data => {
-        Object.keys(me.vnode).forEach(key => {
-            delete me.vnode[key];
-        });
-
-        Object.assign(me.vnode, data.vnode);
-
-        me.syncVdomIds(me.vnode, me.vdom);
-    }).catch(err => {
-        console.log('Error attempting to update component dom', err, me);
-    });
-}</code></pre>
-    <p>Obviously, using a remote method works asynchronously. What happens under the hood is that the app worker
-        will send a postMessage to the main thread, main a postMessage to the VDom worker,
-        vdom will send back the response to main and main forward this to app.
-        We can reduce the routes once SharedWorkers are supported.</p>
-    <p>You can directly promise messages to a target worker or the main thread as well.
-        As an example: component.Base: updateStyle()</p>
-    <pre><code>updateStyle(newValue, oldValue) {
-    let delta = Style.compareStyles(newValue, oldValue);
-
-    if (delta) {
-        Neo.currentWorker.promiseMessage('main', {
-            action: 'updateDom',
-            deltas: [
-                {
-                    id   : this.id,
-                    style: delta
-                }
-            ]
-        }).then(() => {
-            console.log('Component style updated');
-        }).catch(err => {
-            console.log('Error attempting to update component style', err, this);
-        });
-    }
-}</code></pre>
-    <p>This allows you to send messages directly to the main thread or to a different worker.
-        In case the target is not main, neoteric will send the message to main and from there to the target worker
-        and afterwards forward the reply back to the origin.</p>
-</article>

package/docs/tutorials/06_EcmaScript6Plus.html

@@ -1,10 +0,0 @@
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Guide: EcmaScript 6+</span>
-</div>
-<article>
-    <h3>Some useful resources:</h3>
-    <p><a target="_blank" href="http://es6-features.org/#Constants">es6-features.org</a></p>
-    <p><a target="_blank" href="https://dev.to/dipakkr/es6-a-comprehensive-guide-to-learn-es2015-es6-2ao1">dev.to/dipakkr</a></p>
-    <p><a target="_blank" href="https://flaviocopes.com/es6/">flaviocopes.com/es6</a></p>
-    <p><a target="_blank" href="https://www.telerik.com/blogs/es6-syntax-features-and-additions">telerik.com/blogs</a></p>
-</article>

package/docs/tutorials/07_WebWorkers.html

@@ -1,9 +0,0 @@
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Guide: Web Workers</span>
-</div>
-<article>
-    <h3>Some useful resources:</h3>
-    <p><a target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers">developer.mozilla.org</a></p>
-    <p><a target="_blank" href="https://www.html5rocks.com/en/tutorials/workers/basics/">www.html5rocks.com</a></p>
-    <p><a target="_blank" href="https://bugs.chromium.org/p/chromium/issues/detail?id=680046">bugs.chromium.org</a></p>
-</article>

package/docs/tutorials/08_DomEvents.html

@@ -1,7 +0,0 @@
-<script src="../../../../Users/tobiasuhlig/IdeaProjects/pdcat/pdcat-webapp/src/main/resources/static/app/ux/GridToolTipPlugin.js"></script>
-<div class="neo-header-text-container">
-    <span class="neo-header-text">Tutorial: Dom Events</span>
-</div>
-<article>
-
-</article>