Phlex ActionView template handler

[nolantait]

Not a full implementation yet but I wanted to get your thoughts on this. What do you think of Phlex as a templating engine in rails?

I've been doing this in a static site generator I've been hacking away on and noticed some people discussing on the phlex-ruby: https://github.com/orgs/phlex-ruby/discussions/589

# app/views/posts/show.phlex

h1 { @post.title }
article(class: "prose") { @post.body }

[bradgessler]

I had this thought a while back, but as I used Phlex more I’m glad I didn’t go down the templating path.

What I realized I was getting tired of is initializing classes with the same arguments in the controller, so I created https://github.com/rubymonolith/superview

In the README I only show examples of inline views, which is great for prototyping (think Sinatra), but in your case you probably want the view files in your ./app/views directory. For that create your view files at ./app/views/foo/show.rb, then in the controller:

class FooController
  include Superview::Actions
  include Views::Foo
end

This will use Zeitwork conventions to load the view files that correspond with your actions, just like you’d expect with Rails templates, but it perseveres the OO-composability goodness of Phlex.

[nolantait]

Very cool, I'm in love with Superform. Should have checked out more of your repos.

[joeldrapper]

Hey @nolantait 👋

Thanks for proposing this feature through your PR. The community has voiced similar requests, so it's clearly a point of interest.

However, I believe incorporating this into phlex-rails poses challenges, as it conflicts with some of the library's fundamental principles:

1. Safety: Phlex minimizes dependency on distant instance variables, reducing bug risks—a benefit that could be compromised with your proposed feature.

2. Performance: Phlex's speed gains come from bypassing ActionView template lookups. Introducing templating capabilities would negate this advantage.

3. Consistency: While Phlex may initially seem at odds with ActionView, its object-oriented approach to views actually aligns closely with idiomatic Ruby. Over time, this consistency proves beneficial.

Given these constraints, it seems more fitting for your feature to exist as an extension gem rather than a core addition.