Inline tags a step in the wrong direction?

[davekaro]

In #755, support for inline tags was added. You can now render content like h1("Hello") as well as h1 { "Hello" }.

When I first saw this PR, I was not sure how I felt about it because after writing about 600 views/components in my app, I've never really wished I had this ability. Reading https://judoscale.com/blog/phlex-not-erb helped explain the major downside of supporting this way of setting the content, namely the structure of the HTML becomes more obfuscated. See this quote from the section titled "Seeing the shape of the markup":

I argue that Phlex solves that by encouraging you to shape your Ruby just as you would your HTML—after all, the structure of HTML elements and attributes very closely mirrors the structure of Ruby blocks and keyword parameters.

By supporting content as the first positional parameter, can we still say "Phlex encourages you to shape your Ruby just as you would your HTML"?

Another downside I realized when working on some code this morning, a simple component like this:

h1(class: "text-green-500") { "Hello" }

might also be written as:

h1("Hello", class: "text-green-500")

and now I have to decide every time whether I want to use the block form or the positional param form.

Would love to hear others thoughts on this. In the linked issue, the only upside of supporting this method of setting content was to make migration from another (legacy) gem simpler. Is this enough reason to add this feature? Are there benefits I'm missing?

[joelmoss]

FWIW, I totally agree here 😟

API consistency, and familiarity with the shape of HTML has been really valuable based on my experience of Phlex.

There are also caveats to supporting inline tags, such as not allowing nesting...

h1(h2("Hi"))

or mixing the positional arg and a block...

h1("Hello") { "World" }

And of course this will also prevent the use of positional args for any current or future use. While you may not be able to think of a use for them right now, but by supporting inline tags, and reserving the (first) positional arg, you are shutting that down completely. I actually use positional arguments in some tags and custom tags, so I would expect this to break some of my code ☹️

I see no benefit to this, other than perhaps it looks a little nicer all on one line, which with all else being equal, I would be a fan of. But unfortunately that is not the case here.

[joeldrapper]

Thanks for your feedback on this @davekaro. @willcosgrove and I went back and forth on this a bunch before merging the PR and maybe we made the wrong decision. Some things we considered were

Arguments for

1. it’s intuitive
   1. most Rubyists seem to assume you can do this
   2. most Phlex alternatives support this
   3. AI sometimes predicts this;
2. it’s faster — leaf nodes (containing only text) don’t need to create a new stack frame, allocate a Proc or go through yield_content; and
3. it’s more consistent with plain and less likely you’ll end up with a void string bug (which is very difficult for us to detect and warn you about).

Arguments against

1. we can’t go back if we do this now;
2. it will make rendering an element inconsistent with rendering a component when it comes to passing in content;
3. it provides two ways to do the same thing; and
4. it’s inconsistent with the shape of HTML.

I’m not against reverting this change.

[hangsu]

My opinion:

3. it’s more consistent with plain and less likely you’ll end up with a void string bug (which is very difficult for us to detect and warn you about).

This is the most compelling "for" argument

3. it provides two ways to do the same thing; and
4. it’s inconsistent with the shape of HTML.

These are very compelling "against" arguments

Overall, I don't think the benefits outweigh the costs so I'd be in favor of reverting. If it did ship, I'd be poking around for ways to raise if inline tags were used.

[Vagab]

agree with @hangsu here. I think the flexibility of this approach is nice but having two ways to do the same thing would be worse. Steering people away from bad practices is something I miss in other ruby gems a lot sometimes

[joeldrapper]

Some other thoughts:

1. I’ve been using Phlex for absolutely ages and have never needed or missed inline content. While it may be a steeper learning curve, that might be worth it if the long-term satisfaction is high.
2. Just because a feature exists doesn’t mean you need to use it.
3. That said, Phlex has always taken an approach of trying to steer people away from bad practices. For example, to this day, you still can’t define an onclick attribute. 😅

[joeldrapper]

Thanks for your feedback @davekaro, @joelmoss, @hangsu, @Vagab. We decided to revert this change.