Feature proposal: vnode hooks about purescript-flame HOT 9 CLOSED

Hello @chekoopa , thank you for your suggestion.

Some use cases can be accomplished by (carefully) using the innerHtml attribute (e.g., markdown rendering) or using signals. That being said, keys, thunks and hooks would indeed be a great addition.

Perhaps you could adapt the work for hooks in your fork to flame? PRs are always welcome :)

As for keys and thunks, I think neither is very complex to implement (key for example is just a snabbdom attribute). Maybe this could fit in the following release, tho I still need time to research.

from purescript-flame.

Both innerHtml and signals (and even effects with getElementById, we used to have that) are dirty hacks, IMHO.

The problem is Hedwig having a different 'vnode baking' architecture, so I can't adapt it straightforward. However, I've researched your code for a bit and have some picture in mind about hooks implementation, would try carve some time and make a fork.

BTW, key also can be added as NodeData. It may be a little unusual to have a vnode key as an attribute, but Hedwig has the same UX.

from purescript-flame.

Both innerHtml and signals (and even effects with getElementById, we used to have that) are dirty hacks, IMHO.

More often than not, hah.

The problem is Hedwig having a different 'vnode baking' architecture, so I can't adapt it straightforward. However, I've researched your code for a bit and have some picture in mind about hooks implementation, would try carve some time and make a fork.

Sure!

BTW, key is also can be added as NodeData. It may be a little unusual to have a vnode key as an attribute, but Hedwig has the same UX.

That makes it easier to use/modify functions that construct nodes.

from purescript-flame.

I wonder if hooks should have the message return type, like events.
It seems to be possible (like, wrap hook functions with updater), but we also should somehow include VNode mutation, and the current UX (Hedwig-based) is only acceptable for foreign functions (because of unsafe VNode mutations).

So, I'm now implementing the unsafe-foreign hook feature.

from purescript-flame.

Actually, safe-ish VNode mutation could be reached with map-like hook function, which returns new VNode object, and the under-the-hood wrapper performs data replacement (I don't know what would happen if we replace the whole node).

And all hook functions are Effect Unit, if we're talking in Purs conventions.
So, if we would make wrapped Purs-compatible hook functions, they would look like this:

¹ Don't know whether this hook should be implemented.

But, there's a big problem about vnodes. Snabbdom doesn't restrict adding custom properties to VNodes, and we are using that in our Markdown implementation. Elm Markdown library uses local model data (https://github.com/evancz/elm-markdown/blob/3.0.2/src/Native/Markdown.js), which stays with the node and is used for diffing. We add two fields, too, as for a local node model.

exports.start = function (options) {
    return function (rawText) {
        return function (vnode) {
            return function () {
                vnode.raw = rawText;
                vnode.options = options;
                vnode.elm.innerHTML = marked(rawText, formatOptions(options));
            };
        };
    }
};

exports.patch = function(options) {
    return function (rawText) {
        return function (oldVnode) {
            return function (vnode) {
                return function () {
                    var oldRaw = oldVnode.raw || "";
                    var oldOptions = oldVnode.options || null;
                    vnode.raw = rawText;
                    vnode.options = options;
                    if (oldRaw === rawText && optionsEqual(oldOptions, options)) {
                        return;
                    }
                    vnode.elm.innerHTML = marked(rawText, formatOptions(options));
                };
            };
        };
    }
};

With Purs-based implementation it wouldn't be possible. If only we added another field, like model :: Object Type, which would be empty for default nodes, but is usable with foreign and unsafe functions for model operations.

from purescript-flame.

Would all of that be easier if we changed the wrapper functions e.g. Renderer.purs to foreign calls? Similar to what hedwig did. Maybe as more features are added, changing (a bit of) type safety for easiness and performance is an acceptable trade off.

I am not sure I follow the need for the local vnode model field. Aren't all vnode manipulations done in unsafe js? Would it be just to feed the initial values?

from purescript-flame.

It depends on what you have in mind for Flame. I'm not sure what functions could be converted to foreign (still not fully examined all the renderer internals), but the current state of code is pretty sturdy. The performance point is about benchmarking, I think.

By design, these manipulations are unsafe. The thing I've described above is kind of concept for Purs-compliant low-level FRP vnode hooking. Hooks themselves are rather advanced feature which used mostly by library developers (in Elm it was possible before the 0.19 release).
So, unsafe hooks are fair for now.

Aside of hooks, keys, and thunks Snabbdom offers module feature. But something tells me that would be too bloated.

from purescript-flame.

A question about naming conventions. What should we use for hooks' name?

• own naming, like atInsert. I've used that in Hedwig, it makes hooks distinctive from other attrs.
• event-like naming, like onInsert. It doesn't interfere with events.
• plain hook's name, like insert.

I'm now sticking with the first variant, but can change it at any moment before PR.

from purescript-flame.

Yeah I plan on adding benchmarks next. The types for hooks, and the first naming convention, sound fine. I will try it out on own my markdown generation too.

from purescript-flame.