Temple - HTML DSL for Elixir and Phoenix

I just released the first version of Temple: an HTML DSL for Elixir and Phoenix!

You can read this blog post or the docs for more information!

13 Likes

Out of curiosity - what are the advantages over Phoenix.HTML?

This library is not a competitor to Phoenix.HTML, in fact Temple uses Phoenix.HTML as a dependency.

Temple needs to wrap Phoenix.HTML to make the functions work with the macros.

The reasons are related to how the markup is collected at runtime and there is some complexity around the anonymous functions used in the form_for and inputs_for functions from Phoenix.HTML.

And the same question regarding to https://github.com/zambal/eml

Reminds me of an in between jade and haml.

Looks nice.

Looks nice! Well done :star:

About the existence of similar libraries, I think the fact that different authors experiment with different approaches is a positive sign of a good open-source ecosystem.

5 Likes

Ah I like code-syntax based DSEL’s like these, it makes it much easier to just use normal coding practices and functions instead of some unique syntax that makes it more difficult. :slight_smile:

ul class: "list" do
for item <- @items do

I’m guessing that it works by having each expression in the body list be placed into the final template, and something like for that returns a list just inlines each element of the list as a standalone expression?

defcomponent

Why use defcomponent over just a function call, or is it to work better with phoenix’s liveview stuff so you can inline it all more?

In the example, could:

  defcomponent :nav_item do
    div id: @id, class: "flex flex-col" do
      div @name, class: "margin-bottom-2"
      div @description
    end
  end

Be instead implemented just as:

  def nav_item(item) do
    temple do
      div id: item.key, class: "flex flex-col" do
        div item.name, class: "margin-bottom-2"
        div item.description
      end
    end
  end

And thus be used like nav_item(item) or nav_item item instead?

Components can also take children if passed a block and are accessed via the @children variable.

Is there any way to make it fail to compile if children are passed in when they aren’t used, or fail to compile if no children are passed in when they are required?

2 Likes

I’m guessing that it works by having each expression in the body list be placed into the final template, and something like for that returns a list just inlines each element of the list as a standalone expression?

The macros expand to functions that when called, will emit markup into some state. If they are called inside a loop, they will be called multiple times.

Why use defcomponent over just a function call, or is it to work better with phoenix’s liveview stuff so you can inline it all more?

defcomponent is used to create a macro like div or span, except it is given the name you pass, and the props you pass it are replaced in it’s body.

If you create a function that calls the temple macro, it will return {:safe, "your markup"}, but it will not be emitted into the end result unless you call it with the partial macro.

  def nav_item(item) do
    temple do
      div id: item.key, class: "flex flex-col" do
        div item.name, class: "margin-bottom-2"
        div item.description
      end
    end
  end

temple do
  div do
    partial nav_item(item)
  end
end

will emit

<div>
    <div id='some-id' class='flex flex-col'>
        <div class='margin-bottom-2'>Some Name</div>
        <div>Some Description</div>
    </div>
</div>

Is there any way to make it fail to compile if children are passed in when they aren’t used, or fail to compile if no children are passed in when they are required?

It doesn’t do that right now, but I’m sure it’s possible!

2 Likes

Just wanted to say that Temple looks awesome! I am pining for it to get LiveView integration :slight_smile:

3 Likes

Just released v0.1.1!

Single arity tags will now escape content passed to them, functioning the same as calling the text macro.

temple do
  div "<div>HELLO</div>"
  text "<div>HOWDY</div>"
end

# <div>&lt;div&gt:HELLO&lt;/&gt;</div>
# &lt;div&gt:HOWDY&lt;/&gt;

CHANGELOG

3 Likes

Just released v0.1.2!

Components now work correctly when requireing their module (as opposed to calling import).

defmodule MyComponents do
  import Temple
  
  defcomponent :btn do
    input type: "submit", class: "btn btn-red lots-of-padding", value: @text 
  end
end

defmodule MyWebView do
  require MyComponents, as: C
  
  def render_a_template("index.html") do
    temple do
      form do
        label "Your Name", for: "name"
        input name: "name", type: "text"
        
        C.btn text: "Submit 
      end
    end
  end
end

#  <form>
#   <label for="name">Your Name</label>
#   <input name="name" type="text">
#   <input type="submit class="btn btn-red lots-of-padding" value="Submit">
#  </form>

CHANGELOG

2 Likes

Just released v0.2.0!

This release introduces the radio_button/4 macro from Phoenix.HTML.Form (which was somehow forgotten during the initial release).

Special thanks to @shritesh for the contribution!

3 Likes

Just released v0.3.0!

Please see the changelog for all the details.

2 Likes

In case anyone has questions or would like to discuss the future of Temple, feel free to drop me a line in the Elixir Slack: https://elixir-lang.slack.com/messages/CMH6MA4UD

2 Likes

v0.4.0 has been released. Please see the changelog for all the changes.

2 Likes