Fireblast - Html render with module components for Phoenix inspired by React

Nice, but I am still trying to grasp what is the difference between this and regular EEx? You mean the fact that you provide sigil_x?

So EEx is a string template language. Phoenix adds some html related things on top of it.

There are also great engines for different templating formats.

If you know and like templating you probably don’t get a lot of value out of Fireblast.

But the reality is that more people know React than templating languages at this point. That might change.

If you do know React you know how easy it is to create reusable components that is what I’m trying to imitate.

Example:

Phoenix:
<a href="<%= Routes.page_path(@conn, :index) %>">Link back to this page</a>

Fireblast would be:
<Link to="index" conn=${conn}>Link back to this page</Link>

So instead of spawning a node process to render React for templating you can possibly use Fireblast

The question is - how does the React component model (or its JSX representation) apply in this particular context - other than appealing to developers who are already familiar with it (for better or worse)?

My point isn’t to critique your contribution - thumbs up for sharing - but to encourage thinking (and perhaps develop a more compelling rationale for somebody to use this).

React and Redux reference Elm as prior art.

Interestingly I’ve never found a reaction by the React community to the conclusion of the Elm community that the component model does not work in a single source of truth architecture.

Richard Feldman came from React and reports on components not scaling well in Elm Europe 2017 - Scaling Elm Apps. He reports that the component approach introduced too much accidental complexity over an approach that managed the model, view, and update aspects separately. It roughly focuses on “narrowing types” on the inputs of the constituent functions that comprise the model update and view render in order to limit the complexity of each constituent function to make everything easier to reason about.

By contrast in React/Redux a component often has to rifle around in the whole application model to get the information it needs (and therefore is coupled to the model’s layout), pay attention to the props that are handed down by the parent component, possibly use some of the (function) props to affect the local (i.e. non-centralized) state of any of it’s ancestor components, or even receive child components (render props/component injection).

To the benefit of reuse:

The Rules of Three originated from Biggerstaff and Richter in 1987:

• You must have looked at at least three systems to understand what is common across them (and therefore reusable)
• It takes three times as much effort to make something reusable as to make it usable
• You will receive payback after the third release.

And just another opinion:

Often the component mindset goes hand-in-hand with the OO mindset.

I understand that we all like the idea of components but optimal boundaries tend to be much more complicated than that.

So I don’t really have to worry about that as much in Fireblast because I’m doing all the processing at compile time. So we have the same iolists as with regular Phoenix. Though they are split up more probably. I can do some benchmarking on it just to make sure I’m not doing anything dumb.

Fireblast is only the JSX part really at this stage. With integration into Phoenix Live it would become closer to React.

I’ll definitely look at the links you provided because we don’t want to repeat the same mistakes.

The good thing about announcing a project is that you feel guilty for things you haven’t done yet but think have to be done.

One of those things was a basic escaping of variable data passed into the component so people can’t just inject what ever into it. Now with the help of Phoenix.HTML I have a version out.

I do not quite get what you are saying there. Phoenix views have some magic behind to generate functions, but in general Your example can be written as:

Link.render(conn: conn)

Or any other function, as what you call “Phoenix templates” are just functions, exactly like React render functions, with only one main difference - as Elixir is compiled language these functions can be generated during compile-time from external text files. So while I see it as a nice learning project I do not really get what is the improvement there.

Of course you can use what ever module in the <%= %> and you can even use render(YourApp.UserView, "index.html", name: "John<br/>Doe") in there.

But it’s just about how easy it is to read the.

You can use ~E and ~e but they don’t accept #{}

So things like:

list = [1, 2, 3]

render_item = fn item ->
  ~x(<p>#{item}</p>)
end

~x(
  <div id="1">
    #{Enum.map(list, render_item)}
   </div>
)

Is really hard to replicate just with sigils, you can use the EEx do get the same effect.

It just has to do with familiarity. Vuejs look really different from React but at some level they are doing the same things. But in our case we are actually getting the same result because we don’t have to contend with a javascript rendering part.

There are going to be case where I would have a clear win over Phoenix templates. That is with something like a Trans tag.

~x(
  <p>
    <Trans>
      Hello <a href="/world">World</a>
   </Trans>
  </p>
)

Would get translated into

arg9295287e5e664ce9b7eaf95f87226762 = gettext("Hello %{tag1}World%{tag1}", tag1: "<a href=\"/world\">", tag2: "</a>")
{:safe, ["<p", ">", arg9295287e5e664ce9b7eaf95f87226762, "</p>"]}

Compared to having to do that manually for Phoenix templates.

Now I just have to finish my implementation of Trans . It’s not that hard given what I have access to I just have to do it.

I’m not sure why one would need react inspired syntax to create a macro, which translates eex content into a call to gettext. It could just as well be a macro trans called like that:

<%= trans do %>
  Hello <a href="/world">World</a>
<% end %>

That is a pretty good suggestion. I’ll probably implement something like that a long side my implementation of Trans so people that prefer templating also get something

It is not that hard:

list = [1, 2, 3]

render_item = fn item ->
  ~E[<p><%= item %></p>]
end

~E[<div id="1"><%= Enum.map(list, render_item) %></div>]

You cannot use #{} in ~E as these are expanded in compile time, but you can always use <%= %>.