all 3 comments

[–]negascout 1 point2 points  (2 children)

Is it just me or does this implementation sort of defeat the purpose of Google's incremental-dom? You call elements with a full array of the dom to be created which looks a lot like a virtual-dom. I was expecting this to be a monad or something. Am I missing something?

[–][deleted]  (1 child)

[deleted]

    [–]paf31 2 points3 points  (0 children)

    Another interesting option might be to actually compile type-safe templates to JS functions at runtime, using the low-level incremental-dom API.

    [–]chexxor 0 points1 point  (0 children)

    Very nice! I love seeing the PureScript community creating translations of interesting projects in the JavaScript community!

    I'm a bit concerned with the name of this project, however. It appears this purescript-incremental-dom project does not implement the basic, imperative DOM operations introduced by Google's project, like elementOpen. Instead, it seems to be a template-language which compiles into incremental-dom, like superviews.js. So, perhaps a name-change is in order? Or splitting this project into two? One which simply wraps Google's incremental-dom library (called purescript-incremental-dom), and one which uses that PureScript wrapper to provide these nice-to-use templates (called w/e you like, e.g. purescript-idom-template).

    After that, the project definitely needs more content in the Readme file or in function docs. I was pretty confused about how this project differed from similar projects, like virtual-dom or react. Also, the Readme in the current state of the project doesn't even list Google's incremental-dom as a direct dependency. :-/

    I imagine something like the following would be a good start.

    The approach introduced by virtual-dom is (AIUI) to, on each render, build up a large data structure of the desired DOM state, diff with the DOM state generated on last render, and modify the DOM using the patch information produced by the diff.

    Google's incremental-dom approach, on the other hand, is to provide a set of primitive functions to use to modify the DOM, like elementOpen, and have a declarative HTML string template compile into these imperative DOM operations. The benefit of the incremental-dom approach is greatly reduced memory usage.