I recently started to hack with Elm and I am having quite a lot of fun! Thanks to the community!
After a successful prototype integrating CodeMirror, semantics-ui, elm-markdown and elm-split-pane, I wanted to go a step further and replace elm-split-pane with Golden Layout that makes a remarkable job at Compiler Explorer.
I am wondering if anyone already tried to build an Elm app interacting with Golden Layout or any library with a similar architecture / philosophy?
At first sight it seems kind of hopeless to integrate golden layout with TEA because the library maintains and mutates its own sub-tree of the DOM:
- it takes ownership of a DOM element as its rendering root.
- it builds a sub-tree of containers and splitters.
- the leaf items are instances of user-defined “template component”.
- you can subscribe to all kind of events (item creation, deletion …), so in theory you can track what matters in the Elm model state using a few ports.
- but… human interactions with the layout trigger reshuffling and updates of the sub-tree owned by the library. Although I assume the items are simply moved around so user-defined content integrity is preserved.
The reshuffling of DOM elements performed by the library on human (or programmatic) interaction prevents from managing that part with Elm as part of a regular view update.
Is it correct to say that TEA enforces that one can only update a single view backed by a single root node of the (virtual) DOM? Or is it only a restriction of
My hope to integrate with golden layout would be to find a way to control several DOM nodes instead of just one. For instance the view function could return a mapping from DOM ids to
view : Model -> Dict String (Html msg), and there would be one virtual DOM maintained for each key.
With such a
view function, I could manage the leaf items with Elm regardless of the rest of the DOM sub-tree owned by golden layout
Does this makes any sense? Is there a better solution that I’m not aware of?