Haml/Slim support

[oneiros]

Volt looks amazing and I cannot wait to try it out, but there is at least one thing missing for me: One or more alternative template languages that are less verbose than html.

I know Haml is not for everyone and I would not expect it to be the default, but after 15+ years of web development, I really enjoy anything that saves me time writing my html templates.

It need not be Haml. Slim is nice as well. Or something else entirely that is in the spirit of the two.

At the very least it would be wonderful to have a well-defined interface to plug-in alternative templating engines.

Sorry if this has been asked before. And of course this not a big showstopper. Still, I would love to hear your thoughts about this.

[dfyx]

We've talked about that a few weeks ago. The main reason why it's hard to add more template languages is that they must be pretty tightly coupled to the reactive value system so everything gets updated.

So while it's not impossible to do, I'd guess the priority for @ryanstout is rather low.

[ryanstout]

@oneiros Yea, a few people have asked for this. It's definitely doable, but not something that we can just drop an existing haml implementation in. Basically, the current template compiler renders to a series of ruby method calls that gets compiled with opal, so it should be somewhat easy for someone to have the haml templates render to the same thing. If someone is interested in working on it, I can walk them through what would be required. Right now I don't have time to work on it, but I may sometime down the road.

[oneiros]

Thanks for taking the time to reply. I never expected this to be a priority. I just wanted to leave this here, so you know there is at least some demand for it.

For now please keep your focus on making volt awesome :smile:

[Ch4s3]

@ryanstout @oneiros I would be willing to jump in and help with this, but I'm not sure I can take it on alone.

[dangerousbeans]

:+1: WANT. :D

[ryanstout]

@Ch4s3 sorry for the late reply. I would love to have someone work on haml support. Feel free to hit me up on gitter (https://gitter.im/voltrb/volt) and we can chat about it.

[ryanstout]

I put a few details on adding HAML support here: https://trello.com/c/4pCyUCfy/50-haml-support

If anyone wants to tackle it let me know. Thanks

[dangerousbeans]

As an idea, could we compile the haml pages to erb, then let everything run as normal? o.O

[ryanstout]

@dangerousbeans so volt doesn't use erb, since it needs to know how bindings fit into the Dom, where as erb just generates a string. You could have haml generate Volts compiled ruby binding structure. When I get some time I can try to document the compiled template/binding data structure.

[dfl]

Swappable templating engines would be very appealing. Perhaps there is a way to use a modified version of tilt? https://github.com/rtomayko/tilt

[Ch4s3]

That's pretty cool @dfl

[phoenixweiss]

I think Slim support would be an amazing deal to Volt

[ylluminate]

:+1: I think the recently added tilt support for Opal may help this all the way around: https://github.com/opal/opal/commit/bac86b48e93cfb1abe101e85c4dc729550480b26

[ryanstout]

@ylluminate so tilt support won't help. What you need to understand is that tilt is designed to take a template and a context object and render a string. All of the template processing and ruby code is evaluated at render time. In volt, we need rendering to happen on the client side, with additional context information to know how to update the DOM when the data in the bindings changes. So any supported templates (with full support) are going to need to integrate or customize an existing parser.

[ylluminate]

Gotcha @ryanstout, hadn't put any thought into it at all. Just saw this last remark pop up and saw that @jeremyevans had done that with tilt so wanted to make that (now obviously erroneous) connection.

[ASnow]

For slim use https://github.com/ASnow/volt-slim

[dangerousbeans]

Give this a try: https://github.com/CollaboTree/volt_haml

I've been running haml templates in my volt project for ages now

[undercase]

I'm working on this right now.

[ylluminate]

@undercase great! Are you working off of what @dangerousbeans beans did or a new effort for integration? And are you doing both haml and slim?

[undercase]

I'm doing a new effort for integration, starting with haml, then slim. I've got a lot of experience with file-parsing and data structures representing file trees, so I think I can definitely handle it.

[undercase]

Doing this properly will require a large overhaul, it looks like the entire codebase is set to accept HTML and convert it to an intermediary data structure for the bindings, rather than accept haml and convert it to the data structure. Our best bet is to create a new repository for a custom haml -> html converter which preserves the Sandlebars syntax and bindings. The alternative is to rewrite the ComponentTemplates' Preprocessors module to account for different ViewParsers.

[undercase]

I've decided to go with the former option. This is how I will write the parser:

It will be a fork of the HAML to Sandlebars parser. I will code it to convert from HAML-style syntax for control flow and bindings to Sandlebars syntax. I need to know all of the enhancements Sandlebars adds to HTML in order to account for each of them in the parser.

[ryanstout]

@undercase Yea, volt has a data structure that templates are compiled to (and can be compiled from anything). I need to write a spec for it, but haven't had time yet. Basically, it looks like this:

{
  '/template/path1' => ['template html <!-- $1 --><!-- $/1 -->', {1 => Proc.new {... EachBinding.new...}}],
 ..
}

The html comments are placeholders for the bindings. You should be able to generate the same data structure without using the Sandlebars parser. Though there's a few things with the way templates are split that you might need to copy. I'm pretty busy for the next few days, but we can chat in a few days if you want, and I can help point you in the right direction.

Thanks!

[undercase]

I can't wait to chat! Drop me a line at 682-597-6360, I have a few questions.