Even though attributes and assigns (from template) have the same @ syntax, they are totally different things. When a template is rendered the assigns as passed as parameter, however you are trying to access a module attribute, witch will never work.
One solution you can use is private functions, however you need to be sure that the template is part the module where you define your private functions. For example in classic phoenix you can do this in your *_view.ex files, because the rendered templates are part of that module.
Another solution is to define functions in one module and import them in your template:
I just want something like this in JavaScript to get it out of function and prevent to duplicate coding, both of solutions are creating duplicate and if I am force to create function, I prefer to put all the list inside function instead of calling @tailwind_settings again
I don’t see how making a function creates “duplicate coding”, either using it from attribute or defining it directly in the function has the same effect on the compiled output.
Don’t mistake “convenience” for “simple”…
Module attributes are not accessible outside of the modules they were defined in, but as @D4no0 said, you can make a function to expose that module attribute.
I’ve come to appreciate the simplicity of Elixir. A part of that simplicity is how modules work.
Further, your example is just not how HEEX and render/1 works. From what I understand, sigil_H (aka ~H"""""") is a macro that expands @foo to assigns.foo or maybe assigns[:foo], I don’t really know.
So you have to put things inside the assigns var for it to be seen in the HEEX macro.
I kind of agree that this is “magic”… and is confusing… and why I dislike Rails. I kinda wish HEEX was a macro that took an arg to make things less confusing…
def render(assigns) do
assigns = assign(assign, :thing, "Hi, mom!")
heex(assigns, """
<div><%= @thing> %></div>
""")
end
To me, that makes it more explicit that you can’t use module variables in render/1.