Making Handlebars work: Should riot-tmpl ignore {{expr}} but not {expr}? about tmpl HOT 3 CLOSED

@GianlucaGuarini @aMarCruz Greetings!

Would it matter if the implementation of this riot-tmpl be improved? In the brackets.split function, instead of using some looped RegExp, could we use a parser instead like acorn?

The benefits that I could think of right now would be:

• Better solution for the problem. String parsing vs RegExp.
• Theoretically, we should now be able to handle REAL 100% Javascript expression within { }. ie:

{ (function dunnoWhyWhouldAnyoneDoThis(){return "but atleast its 100% :)"})( ) }

• I think it shouldn't consider {{$ 'handlebar_helper'}} as a template and skip it.
• A more maintainable codebase.

I'm new to this open source community and contribution but I'd be very much willing to learn, receive constructive criticism. Riot.js is awesome the philosophy it is built under.

I'll be starting to implement this. Please let me know your thoughts. Cheers!

from tmpl.

@aMarCruz was working on the new compiler here https://github.com/aMarCruz/new-riot-compiler so at moment I don't accept pull requests changing the core of the current one. Honestly mixing handlebar templates with riot templates sounds to me a really bad idea anyway independently from the parser. I will work soon on the current parser to implement the sourcemaps asap. Thanks for your question and good luck

from tmpl.

Oh I see, but it seems he's moving it to a TypeScript codebase. Isn't TypeScript out of riotjs' philosophy of being minimalistic? (Type noise)

I'm using a custom build and I need my components' html to read from some global config before being compiled as a riot component. I suppose I could use mixins or even change the custom riot template braces. But I'd rather this custom build's power to do it

Goodluck!

from tmpl.