Polymorphic Phlex HTML tags

[bradgessler]

I've been building a demo application for Phlex at https://github.com/rocketshipio/oxidizer-demo that's "Phlex to the Max"

One idea I ran into is one for what I call polymorphic tags. Here's the idea: let's say you're building a form helper like this:

class UserForm
  def template(&)
    label field(:name)
    input field(:name)
  end

The implementation is at https://github.com//rocketshipio/oxidizer-demo/blob/6e30bd2197a2064714e8ad5edd88ec018f5c7dcd/app/views/phlex_form.rb#L62-L79

In this case, the field method returns a Field class that responds to label_attributes and input_attributes. The Phlex input and label method checks to see if their respective attributes method exists, and if they do, it calls them and uses those attributes.

This could work well for hyperlinks and images too. For example, let's say a user model has a profile_image_url that represents the user. On the user class, the following could be implemented:

class User
  def img_attributes
    { src: profile_image_url, alt: name }
  end
end

From our Phlex code we could then pass an instance of a user straight into an img tag and it will know what to do:

class ProfileBadge
  def template
    h2 { @user.name }
    img @user
  end
end

Another proposal I'd add for polymorphic tags is accepting a component as the first argument and rendering it as an immediate child. For example, a list could be rendered like this:

ul do
  li ItemComponent.new
end

This could be similarly useful for Ruby classes, like User, that want to have a component associated with them:

ul do
  @users.each do |user|
    li user.item_component
  end
end

I suppose the same method checks could happen as above: if an li_component method is present on the User object, it would render that component. I think this might be a little "too polymorphic" since you'd have to wonder from looking at an object if it's returning attributes or a component. To keep things sane, I'd keep the *_component method check out and just make it possible to pass a component into the first argument and it render as a child.

[bradgessler]

Another thought: instead of a *_attributes method per tag, have a single method that returns attributes. The method would be called with an arity of 0 or of 1. If it’s called with an arity or 1, it includes the calling tag. That would allow methods to be constructed like this:

def html_attributes(tag)
  case tag
    when :input, :button 
      { name: field_name(@name), id: field_id(@name), value: @value }
     when :textarea
       { name: field_name(@name), id: field_id(@name) }
  end
end

The advantage this would have is keeping all html attribute generation into one method, making it easier to find and more likely to stay together in a codebase.

This approach would also be advantageous for broader HTML attributes. For example, all Ruby ActiveRecord objects might implement something like this on the ApplicationRecord model:

def html_attributes(tag)
  case :a
    { title: title, href: url_for(self) }
  else
    { title: title }
  end
end

When this model is passed into a tag to render, it would always inject a title attribute to the HTML tag; thus improving accessibility.

It’s also possible to include the attributes provided to the Phlex HTML call so the attributes method can respond different based on all of the provided html attributes. Here’s what that call would look like:

input field(:name), validation: false

Phlex would then call Field#html_attributes :input, validation: false

One thing I don’t like about this is the same approach would be achieved by the following:

input field(:name, validation: false)

Which would set the state on the object that fields returns that generates the desired HTML attributes.

The same effect could be achieved with *_attributes method via method missing.

[bradgessler]

Another consideration for this API: the object should also be capable of returning content for an element to be rendered within the content block. For example, a textarea tag renders its value inside the tag, so the methods on the target object would look something like this:

https://github.com//rocketshipio/oxidizer-demo/blob/309f009e0c3ff429e087148dec35594474c00a5f/app/views/phlex/phorm/field.rb#L35-L41

Here's a more contrived example where I created a component for a lable that wraps the label value in a strong tag:

https://github.com//rocketshipio/oxidizer-demo/blob/70ce8760936f2e31e8ac4c0b520206575574a47f/app/views/phlex/phorm/field.rb#L31-L33

One thing I don't really like about this is that it's not a label per-se; rather it's the inside of a label. That said, it seems to make sense for a _content method to be capable of handling both values and components to be consistent with the Phlex API.

[bradgessler]

I opened a Draft PR at #576 to continue the discussion.

The demo app has been updated to work against this proposed API.