On a side note, I'm pretty sure this filter eliminates the need for the syntactic sugar I'd previously worked on for CrystallineElement, so I can standardize on just inheriting from LitElement directly and then add my two controllers manually. Awesome sauce! (ACYMI, they're controllers which essentially replicate Stimulus light DOM functionality for Lit elements, aka actions and targets.)

Update https://github.com/ruby2js/ruby2js/blob/master/docs/src/_docs/filters/lit.md too?

There's one outstanding bug I saw which is that any ivar set at the class level (like @Styles for example) is turning into a reactive property.

@styles now feels wrong, it probably would be better as @@styles. But there is another bug there that I will address in that @@properties it isn't merged correctly with other inferred properties. I also want to make that a deep merge so that one can, for example, declare a property as attribute: false and allow inferencing to infer the type.

I also plan to update the Rails example to the latest Lit example (it currently is based on the polymer LitElement example).

P.S. As always, feel free to directly commit.

P.P.S. I feel uneasy about "Automatically add the html tagged literal return when necessary for any method, not just render", but real world usage is the best way to figure out if this is problematic.

I feel uneasy about "Automatically add the html tagged literal return when necessary for any method, not just render", but real world usage is the best way to figure out if this is problematic.

Well, perhaps that's a step too far in the magic department, but if so, I think we'd want to back out of updating render as well (aka you still need to prefix the string with html). I feel weird about having render be special among methods. (the use case here is I will often break my render method up by putting bits of templates in other methods in a "partials" type of approach)

partials is definitely a valid use case -- just document it. Not having to annotate strings as HTML is definitely magic, but very convenient.

While it made me feel uneasy, the more I think about it, the case I would be concerned about is rare... a return statement that returns a constant string (possibly with interpolation), where the first character is a less than sign.

That being said, ideally there would be a way to indicate that a string is to be returned? Perhaps as simple as enclosing the expression in parenthesis? I believe that is enough to defeat the current filter logic, so perhaps document it and count it as a win?

@rubys Looks like the parenthesis doesn't short-circuit the logic, but assigning the string to a variable first and returning that does, so probably just need to document that.

Any objections to this pull request being merged? I was in the process of making a number of upgrades to the Lit filter (and you, in fact, completed a number of these changes for me - thanks!) and I would like to resume making fixes/upgrades and then make a release. At the moment, lit is broken on master which is what is preventing a release containing a CLI...

@rubys Yeah I was hoping to get to the docs updates but haven't had time yet. Features should be solid now, so let's merge and I'll work on docs soon.

Your Render PR Server URL is https://ruby2js-pr-141.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-c5icobbru51k3sq4qgk0.

I noticed website builds weren't working on Render anymore, so I upgraded some dependencies (Bridgetown, the quick search plugin which now uses Lit 2, and Shoelace). I also realized I'd forgotten to turn on PR previews, so now we have those as well. =)