Production ready?

[orestis]

Hi! By chance I was looking for something exactly like this project, I have some existing application with Handlebars and now have to deal with form editing and data binding, and would like to avoid rolling my own virtual-dom if possible.

I see this project is fairly new, do you think this can be used in "production"? I would be happy to find/fix bugs along the way, but I can't afford to alpha/beta test right now.

Thanks!

[atomictag]

Hi there, Yes, it's production-safe (used for a secure banking app..) and well tested although: - the original code base had to be changed for the sake of open source - tests are not shipped because it would take way too long for me to modify them to suit an open project My suggestion is to give it a go - it shouldn't be too difficult to try it out. Big forms with handlebars become quite nice indeed if state is preserved across renders. I am happy to help wherever possible

…

On 30 May 2017, at 17:48, Orestis Markou ***@***.***> wrote: Hi! By chance I was looking for something exactly like this project, I have some existing application with Handlebars and now have to deal with form editing and data binding, and would like to avoid rolling my own virtual-dom if possible. I see this project is fairly new, do you think this can be used in "production"? I would be happy to find/fix bugs along the way, but I can't afford to alpha/beta test right now. Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[atomictag]

Assuming you are already using precompiled templates - and therefore handlebars.runtime.js, another option to try things out could be to selectively precompile with backend : idom only some templates and leave the others untouched. The handlebars runtime is the same (and the default) for all backends - all you need to do is to check which backend has been used to precompile the template in order to choose the appropriate render strategy (innerHtml or similar vs. IncrementalDOM.patch). If you follow a similar pattern as depicted in the examples you can determine the backend from the template function itself (templateFn.backend).

That would just add 2.6 KB of incremental-dom to your project - for a lot of extra fun ;)

[orestis]

Thanks for your answer!

I actually don't use pre-compiled templates at all, at this point all the templates are inline the HTML for easier development. I've tried to bundle incremental-bars for the browser using browserify and rollup but without success. If you have any info on this (is it even possible?) I would be grateful.

Meanwhile I'll try the precompiled route to see how it works.

Thanks again!

[orestis]

For the record:

browserify src/index.js -s Handlebars -o incremental-bars.js produces a reasonable-looking file that fails with:

require.resolve is not a function. (In 'require.resolve(file)', 'require.resolve' is undefined)

And this rollup.config.js :

/*jshint esnext: true */
// rollup.config.js
//import { rollup } from 'rollup';
import resolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';
import builtins from 'rollup-plugin-node-builtins';
import globals from 'rollup-plugin-node-globals';

export default {
    entry: 'src/index.js',
    dest: 'incremental-bars.js',
    moduleName: 'MyModule',
    format: 'iife',
    plugins: [
        globals(),
        builtins(),
        resolve({
            jsnext: true,
            main: true,
            browser: true
        }),
        commonjs({
        })
    ]
};

Produces a few warnings about modules not having default exports. Fiddling around with namedExports didn't produce any meaningful difference so I gave up.

[atomictag]

Yeh it's not hard to fix (would need to remove a "fs" require from the transpiler and probably use the browser dist version of Handlebars). Could change that - had it running on a browser before for testing. I see what would make sense here (maybe I'll pre-package a browser dist or something) However, it is really not advisable to perform the full transpilation + compilation at runtime as it gets quite heavy - so I would really suggest a precompilation step as shown in the examples.

BTW, you may also want to look at morphdom and nanomorph for alternative approaches that may suit your use case.

[orestis]

Wow, I didn't know about morphdom. It might indeed work with my use case. I will have a look. Many thanks! 31 Μαΐ 2017, 12:45 μμ, ο/η Davide Mancuso <notifications@github.com> έγραψε:

…

Yeh it's not hard to fix (would need to remove a "fs" require from the transpiler and probably use the browser dist version of Handlebars). Could change that - had it running on a browser before for testing. I see what would make sense here (maybe I'll pre-package a browser dist or something) However, it is really not advisable to perform the full transpilation + compilation at runtime as it gets quite heavy - so I would really suggest a precompilation step as shown in the examples. BTW, you may also want to look at morphdom and nanomorph for alternative approaches that may suit your use case. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[emudojo]

this looks pretty cool and what I need as a dropin replacement for my 2yold backbone project, question does this supports all handlebar conventions including custom functions ?

[atomictag]

It should support everything Handlebars does. I have used it on tonnes of templates with pretty esoteric things in them without issues. My suggestion is to tweak one the examples like this one and see if it works for you. Glad to help in case you need some support

[blikblum]

@emudojo regarding integration with backbone you may want look at this app: https://github.com/blikblum/marionette.renderers/tree/master/examples/idom-handlebars

[jannesiera]

Is there a way to define properties on element declaratively?

[atomictag]

@jannesiera not sure I fully understand the question - could you pls elaborate on what you are looking for, maybe with a small example?

[jannesiera]

@atomictag yes, of course. Html elements have attributes and properties. Attributes can be set declaratively in the html, but propreties need to be set imperatively through javascript. Like this:

Declaring an attribute:
<element myAttribute="myValue"></element>

Setting a property:

var element = new Element();
element.myProperty = myValue; 

Now, if I want to handle everything in a declarative way in my templates I am restricted to using attributes. This approach has two issues:

1. Some elements might not expose a certain property as an attribute.
2. Attributes don't accept complex data types (like arrays, objects, ....).

This is especially cumbersome when using things like Web Components.

I was wondering if there was a way to provide properties declaratively, as they would get compiled to imperative code anyway. Something along these lines:

<element :startDate="{{dateObject}}" name="{{stringValue}}"></element>

Notice the : prefix to delineate a property from an attribute.

[atomictag]

I see - thank you for the clarification.

IncrementalDOM attr can handle both properties and attributes (see here).

However, Handlebars on the other hand treats every dynamic value as a String so AFAICT it's not super trivial not to get {{dateObject}} in your example stringified by the HB code generator.

I'll put some thoughts on this to see if your suggestion could actually work...
On the other hand you could use a helper to do that:

<element {{prop "startDate" dateObject}} name="{{stringValue}}"></element>

but that assumes you can easily get a pointer to the actual element when the helper prop is executed - which is possible (I do it all the time) but it's not as trivial as it may seem and requires a patched version of incremental-domwhich I haven't released.