Glad you like it!
Hopefully I can get 0.6.0 released soon. I currently am in the market for a new computer, which is one of the reasons why it’s been taking so long.
mhanberg
Expert LSP Core Team
Qqwy
TypeCheck Core Team
I very much like the approach Temple takes in parsing.
Out of curiosity and because I think it improves the readability of templates further by removing more boilerplate, I was wondering if if would be possible to support shorthand class-syntax, i.e. div.large.red.button do ... end being turned into <div class="large red button">... </div>.
Since you are parsing the quoted AST manually, I think this should be possible.
What do you think?
2
cenotaph
Just seen this work, great work!
Out of curiosity, did you do any performance benchmarking with barebones phoenix.html and your library?
It would be an interesting test and maybe +1 for your libraries benefits 
0
Qqwy
TypeCheck Core Team
If you are talking about runtime performance: There will not be any difference, as at compile-time the DSL gets turned into the same IOlist format as .eex-templates are. So at runtime there is not any difference.
2
mhanberg
Expert LSP Core Team
I very much like the approach Temple takes in parsing.
Thanks!
Out of curiosity and because I think it improves the readability of templates further by removing more boilerplate, I was wondering if if would be possible to support shorthand class-syntax, i.e.
div.large.red.button do ... endbeing turned into<div class="large red button">... </div>.
Since you are parsing the quoted AST manually, I think this should be possible.What do you think?
I think that this is technically feasible, but I would have to see some more use cases before considering adding something like that. If you’d like, please open a Discussion on GitHub and we can discuss the feature further!
0
mhanberg
Expert LSP Core Team
Out of curiosity, did you do any performance benchmarking with barebones phoenix.html and your library?
As of the 0.6.0 pre-releases, Temple generates EEx at compile time. So if you were to be using it with a Phoenix project, you can use the Temple.Engine or Temple.LiveViewEngine to further compile the generated EEx using the Phoenix.HTML.Engine or Phoenix.LiveView.Engine, which will be compiled the same way a traditional phoenix project would
So, the compiling will be slower as it includes an extra step, but once you’re at runtime it should be identical to a traditional phoenix project.
2
mhanberg
Expert LSP Core Team
5
soup
In the 6.0 RC, I had this component, which acted as a wrapper around live_redirect to make them look like buttons. It mostly just takes any arguments you pass to it, injects some css classes and passes it all down to live_redirect.
In the release I get an error around protocol Phoenix.HTML.Safe not implemented for #Function<27.16960434....
Calling live_redirect without splat actually works fine, I think it’s to do with the order of expansion inside temples macros (just guessing at how Temple works internally).
Is this kind of component still possible?
defmodule AppWeb.Component.LiveRedirect do
import Temple.Component
# ... snip
# convert any given arguments (as map) to keyword list
# for use in live_redirect
def splat(assigns) do
assigns
|> Map.delete(:inner_content) # needs change/not needed
|> set_defaults()
|> maybe_merge_class()
|> Enum.into([])
end
render do
case assigns[:disabled] do
true ->
span splat(assigns) do
slot :default
end
_ ->
Phoenix.LiveView.Helpers.live_redirect splat(assigns) do
slot :default
end
end
end
end
0
mhanberg
Expert LSP Core Team
soup
Oh geez. Yes, that fixed it.
I knew inner_content had been replaced but the error from elixir tricked me I guess 
and I had left that change on the “future fix” list.
Love Temple, it’s great.
1