:D
@Mosho1 OK, I found documentation for the pattern you were using – and I see that it practically obviates the need for this plugin: https://github.com/sebmarkbage/ecmascript-rest-spread
More specifically, the object spread initializer means some forms of attribute may be invoked as plugins that return objects.
These would still limited in scope: they would need to be pure (ie have all necessary input furnished) – custom attributes are more powerful in that they are provided with the compiled virtual DOM element, meaning they can perform complex logic taking account of other attributes, and potentially replace the entire node. The abstraction is far more powerful.
…but I can see that from the philosophical perspective of completely explicit functional code, this is undesirable in the first place.
Bear in mind, though, that this is kind of how Mithril works anyway: you can still step through the process of custom attribute transformations by debugging from the entry point of
m invocation, but how and when this virtual DOM is transpiled to functional DOM is a detached process run implicitly by Mithril (unless you're limiting yourself to m.render to the exclusion of m.mount / m.module && m.route).
So this kind of deferred process contract is something you have already signed up to implicitly by using Mithril in the first place.