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

Yeah that is what I said, that you can use EEx to get the same results. Sigils have the string interpolation which is pretty typical for trying to accomplish these sort of things.

EEx introduces really nice templating behaviors but like the difference between Vue.js vs React.js, things are close but feel really different for people that aren’t used to this kind of behaviour.

It’s actually a choice the Phoenix HTML takes not to use #{} there isn’t anything inherit that makes it not work. I think it’s fair they don’t want to have two different ways of doing the same thing.

Thanks for providing the example

I think that the reasoning was to avoid confusion about when would expanse happen. Somebody could assume that #{} will take place during compilation of the template, not during execution of one. But in the end the difference is small enough to not be an issue in my opinion.

#{} Takes place during compilation otherwise I couldn’t use it.

You mean the content doesn’t execute? That all depends on you macro strategy.

For example:

~x(<foo something=#{{1, 1}}><bar2 something="a"/><a>2</a></foo>)

Becomes

[
  "<foo something=",
  {:"::", [line: 13],
   [
     {{:., [line: 13], [Kernel, :to_string]}, [line: 13], [{1, 1}]},
     {:binary, [line: 13], nil}
   ]},
  "><bar2 something=\"a\"/><a>2</a></foo>"
]

I guess it’s that way, because ~E is the counterpart to compiled eex template files, which don’t use string interpolations, but eex syntax.

In case of EEx and Phoenix.HTML it ends as:

(
  arg0 = case({1, 1}) do
    {:safe, data} ->
      data
    bin when is_binary(bin) ->
      Plug.HTML.html_escape_to_iodata(bin)
    other ->
      Phoenix.HTML.Safe.to_iodata(other)
  end
  {:safe, ["<foo something=", arg0, "><bar2 something=\"a\"/><a>2</a></foo>"]}
)

But you can use @foo as well and then it will extract the requested values from variable named assigns. So you can do:

def my_func(assigns) do
  ~E[<foo something="<%= @foo %>">…</foo>]
end

my_func(foo: {1, 1})

And it will work as expected. Only “nice fancy thing” I see in your code is that (if I understand your example correctly) is that:

~x[<Foo bar=1 />]

Will be compiled to:

Foo.render(bar: 1)

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.

In that case I say great, and I cross fingers for your endeavour. It is very important to know what is you goal and what solutions are already available. From your words it seems that you are already know why your project exist and you do not “blindly implement it because of reasons”. Great!

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)?

I understand where you’re coming from but I think there’s a more productive way to approach and enlighten each other here.

Both frontend driven and backend driven applications both have learned a lot from each other over the years. It’s now common to server side render your frontend app, we have very sophisticated compilers in frontend development, and we have things like Typescript which mimic the type of languages you could only use in backend driven applications years ago. On the other side of things, Phoenix Live View is a “perfect” example of something that went “ok this SPA stuff on the frontend is pretty cool, let’s take some of this”.

Prior to Live View releasing, if someone came in a backend forum and said “hey I developed this library for doing SPA inside of rails” it would have been incredibly common for at least a couple of people to say “IMO SPA’s are incredibly complicated & complex, and [insert framework / language here] renders fast enough”. The thing that none of these responses understand is that regardless of the downsides, SPA’s (especially a couple of years ago) were unequivocally better than alternatives in “some aspects”.

wrongspotting: the idea of taking someone’s feedback (or idea, or whatever) and saying what’s wrong with it, vs saying what’s right with it, and understanding the perspective.

Maybe there might have been more work to bring spa type features to broader applications (unpoly, alpine, phoenix live view) if there was a broader recognition that there WAS things that spas were better at, rather than just saying they’re wrong for x, y, z reasons.

Here’s my point: Rather than picking apart the model of React (and even componentization), let’s talk about what it does well. Let’s talk about the types of applications we’ll be creating with Phoenix and Phoenix Live View in 3 years time that may pull more inspiration from the frontend world. Let’s ask React devs for code examples of what things are easy to pull off in React that seem like it wouldn’t work well without the component model, and then show them examples that we think mirror that. It’s not enough to say “you’re trying to do this, reconsider because of these principles”. That doesn’t bridge the gap, and it also ignores the great history of both platforms borrowing from each other.

Lastly: the Elm talk you cited, when it talks about React components not scaling, it’s important to understand what people in the Elm community are referring to when they talk about components. Elm commonly talks about the idea of having local methods, state, and views combined being really bad, which is what is generally meant when this is discussed. The important thing to note, is that while React allows you to this, it doesn’t necessarily “mean” that a react component will “absolutely” have states or local methods. Entire React component libraries have been created without any of this.

In their original post, the tag line for the library is “html component library that uses JSX like syntax”. There’s no mention of local methods or state, and if you look at the examples, they’re strictly using html, so it makes me believe you merely saw “react” and “components” in the title of this post and made an entire response that isn’t really applicable here. React components, when used at a rudimentary level, can mostly resemble partials in Phoenix. The only real change here is the DX of using partials vs the JSX type syntax.

I’d also have to subsequently ask you how you’re handling accessibility in your applications, as my general experience is that people that shun frontend component models don’t end up handing the many concerns of accessibility as thoroughly (and this is generally a frontend concern, and frontend people generally reach for components to encapsulate the needed logic).