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.

Yeah, for now.

I might need to let some modules have access to the preprocessed children.

I’m also ensuring that the code makes some sense because I’m parsing the xml, so making sure you are closing you elements and stuff like that is ensured.

But the fundamental reason to create this library isn’t to be cooler or have more features than Phoenix. It’s about being able to port React code easily and make people with React experience more productive.

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?

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.

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 %>