gatlin / alm Goto Github PK

Notifying an input signal shouldn't involve a loop. The signal's ID should just be its position in an array.

Right now the pattern is to completely recreate the virtual DOM tree and then completely re-render the view every time something on screen needs to change.

The vdom should instead be a persistent model initialized with the application which provides a special mailbox to where the rest of the application can send view updates (of some special form).

The vdom would listen to this mailbox and modify the DOM based on what it receives. How it goes about re-rendering these changes is for a separate issue.

Things to consider: how should tree updates be specified?

I keep writing little things while using Alm and I really should put them in the standard library somewhere.

For example, this little routine finds the first ancestor of an element which has a certain class:

    runtime.scope.ancestorWithClass = function(node, needle) {
        function hasClass(node, needle) {
            return (' ' + node.className + ' ').indexOf(' ' + needle + ' ') > -1;
        }

        let haystack = node;
        while (node) {
            if (hasClass(haystack, needle)) {
                break;
            } else {
                haystack = haystack.parentNode;
            }
        }
        return haystack;
    };

A common pattern that is emerging looks like this:

• A single model as a signal reduction
• listens to updates from an "updates" or "actions" mailbox, and
• a view which listens directly to updates from the model signal
• 0 or more event listeners based on events or other existing signals
• 0 or more ports

All of these things need to be visible to one another, of course, but I think a wrapper function or class around App - say, Controller - would be really useful for streamlining everything.

What an App has control over and what it can listen to should be separate.

• If a configuration object is passed, it is expected that separate elements are given for event root and DOM root.
• If a single id is passed, then they are the same.
• If nothing is passed, the defaults are the document body for both.
• If a configuration object is passed but either key is null, default is document.body.

Really it's just there to be a managed scope you can declare variables in.

It should be possible to assign a DOM node a mailbox it sends itself to once it has been (re-)rendered.

Use case: the application requires a canvas to draw on, so you want to initialize a drawing module with the context once it's available. You could listen on the mailbox for that node and be notified every time the node is drawn (or redrawn) and use that to continue with any drawing-related activities.

The current signal system is push-based, which has a number of desirable properties. However, since they do not have values themselves[^1] you can't poll for events, either. In "event/behavior" terminology we have "events" and could use "behaviors."

What is the best way to do this? And should signals be reimplemented a little more rigorously in relation to the App monad?

[^1] that you can access at will. Reducers haven hidden state.

This would entail keeping a cache of all values seen. Depending on the complexity of the signal function this may end up just wasting more memory with negligible performance benefits, but it is worth looking into.

there should be a null check in start that throws an exception. That way people can write code that may create apps and store them until they're needed and re-bind them.

Whether it is based on promises or something homebrewed it would be useful to have a system for orchestrating asynchronous tasks in such a way that reads well in code, is efficient, and which is expressive while making it difficult to write something incorrect.

To steal another term and idea from Elm, I call this hypothetical system "tasks."

Apps which don't have a UI should be simple to declare.

So this

el('div', {
    'id': 'some-id',
    'class': ['class-a', 'class-b']
}, [ /* ... */ ])

Certain elements should have their own mailboxes and listeners so that they can be updated directly. This entails node persistence à la Issue #1 .

The way the vdom diffs children elements is naive and in more complex cases could lead to massive re-rendering of DOM nodes where it isn't strictly necessary.

For now it should probably be combined into the alm source, as it currently has 1 user. I can split it out again later.

Aren't there package managers to copy files for you? I should support them I guess.