Ideas for handling rails form helpers?

[khiga8]

Hello! Our team is in the process of rolling out view_components to our rails app.

Currently we have a ButtonComponent that renders a html button element of a specified type.
We also have a ButtonLinkComponent that renders a html link element styled as a button.

However, we had not considered rails helpers like submit_tag, or f.submit which are bound to a form that we also want to style as buttons. HTML wise, these render something like,

<input name="commit" type="submit" value="Search" data-disable-with="Search" />

Functionally it doesn't seem like replacing these rails submit helpers with <button type ="submit"/> has consequences, but I'm not entirely sure either-- anyone have any idea? Either way, it seems like we should probably preserve form helpers.

I was curious how others have handled rails helpers with their components, or have any ideas for how to approach this.

[joelhawksley]

@fsateler maybe you could answer this one, as you've done some investigation into working with forms?

[fsateler]

So, the rails helpers are basically wrappers around button_tag (https://github.com/rails/rails/blob/46a22ceaff1c8dc8e5a8f5acf6bb9865e46b7768/actionview/lib/action_view/helpers/form_tag_helper.rb#L452-L457). Given you are not using button_tag, but rendering your own button components, I think you need to stop using f.submit or submit_tag.

Unfortunately, I think the future of forms+view_component means somebody coming up with a set of form components, and a few helpers to actually render those components. The basic rails helpers are just printing out html (almost) directly.

[mockdeep]

The Rails form helpers actually do a bit more work than the basic _tag helpers. For example, f.submit changes the button text based on whether the record is persisted or not. f.text_field sets the field name and id attributes based on the field, and properly nests them, e.g.: user[email]. The top level form_with/form_for/form_tag helpers also insert a couple of hidden fields, including the authenticity_token.

They are just generating html, but it would suck to have to rewrite the functionality built into the Rails form helpers that makes it graceful to work with models.

[fsateler]

You are absolutely correct. By "just printing out html", I mean that there is no abstraction you can tap into to inject behavior. This is why libraries like SimpleForm build on top of the rails helpers, rather than integrate with: they end up invoking the same helpers, but prefilling lots of parameters.

That's why I wrote that I think the future of forms+view_component will mean a new library: the rails form helpers simply don't offer a way to inject smarter behavior. Ultimately, a rails check_box is really just a checkbox, it is not a"checkbox component".

[pinzonjulian]

I've been working on this for the past few weeks and I think that Rails already has some awesome conventions for forms that view-component should not have to reinvent.
The solution for this is to create custom form builder methods that override the default rails ones. Take a look at the docs for form builder
https://api.rubyonrails.org/v6.0.3/classes/ActionView/Helpers/FormBuilder.html
And take a look at the actual way rails builds its own tags. (this makes me think that rails had the concept of components all along ❤️)
https://github.com/rails/rails/blob/7556f7c09c9a2e314776b7e2ea78868898cd9209/actionview/lib/action_view/helpers/tags/text_field.rb

You could create your own builder: KhigaFormBuilder which can in turn use view components inside.

class KhigaFormBuilder < ActionView::Helpers::FormBuilder
  def text_field(method, tag_value, options = {})
    # in here you could build any html you want. 
    # You should be able to call your view component for input fields 
    # for example: KhigaDesingSystem::TextField(params)
  end
end

<%= form_for(@dog, builder: KhigaFormBuilder) do |form|>
  <%= form.text_field :first_name %>
<% end %>

The important bit is to allow your view component to follow the same conventions as Rails' default form builder methods which adds attributes like name which is crucial for receiving params in the controller or id which adds an id based on the object of the form. In the previous example the input field's name attribute would be dog[first_name] and id would be dog_first_name.

Talking about the controller, you can specify default form builders per controller:
https://api.rubyonrails.org/classes/ActionController/FormBuilder.html#method-i-default_form_builder

[khiga8]

I think that Rails already has some awesome conventions for forms that view-component should not have to reinvent.
The solution for this is to create custom form builder methods that override the default rails ones. Take a look at the docs for form builder

Apologies for getting back so late! Ooooh, I didn't know It was possible to create custom form builders like this-- thanks for the links! This is interesting and I'll explore this a bit more.

[swanson]

Throwing in my two cents: I don't use view_component with form elements at all. I've had much better results by customizing the FormBuilder (in my case to generate TailwindUI styled markup for input elements) and using CSS for styling "link buttons" that aren't directly in forms (via @apply in Tailwind).

One mental model that I think may be helpful is that the Rails form helpers are already abstracted into components -- and have years and years of battle-hardening and deep first-party support in the framework.

<%= f.submit "Save", class: "btn btn-green" %>

vs

<%= render ButtonComponent.new(text: "Save", color: :green) %>

I'm not sure you're really getting much benefit from ViewComponent in this case.

If you want to make ViewComponents for visual parts of a form (a Card or an InputGroup or a Banner) that will work fine, but in my opinion avoid replacing text inputs, selects, buttons, link_to, etc.

[khiga8]

One mental model that I think may be helpful is that the Rails form helpers are already abstracted into components -- and have years and years of battle-hardening and deep first-party support in the framework.

If you want to make ViewComponents for visual parts of a form (a Card or an InputGroup or a Banner) that will work fine, but in my opinion avoid replacing text inputs, selects, buttons, link_to, etc.

Sorry to get back so late! I'm pretty new to Rails and this isn't something I really kept in mind. Thanks for offering this perspective, I'll keep this in mind as I create components.

[dkniffin]

I'm late to this discussion, but I'm about to embark down this path of figuring out what forms look like in an app using ViewComponent. I wonder if it would make sense to pass in f to the ViewComponent.

pseudocode, not tested:

app/components/button_component.rb:

class ButtonComponent < ViewComponent
  attr_reader :f, :args
  def initialize(f: f, *args)
    @f = f
    @args = args
  end
end

app/components/button_component.html.erb:

<%= f.submit(args.merge(class: "btn btn-green")) %>

Usage:

<%= render ButtonComponent.new(f: f) %>

This leverages Rails's helper abstractions, while allowing the developer to make their own as well.

However, I have not tested this at all, and if there's anything I learned from forms in React, it's that forms are a PAIN to get right and to componentize and such. I'm pretty sure I'm oversimplifying this.

[boardfish]

I think the worry with this solution is that this component is coupled to a form helper - there's an expectation on f that it will respond to submit.

[boardfish]

Dropping some thoughts in here. I haven't solved this problem for myself and my team, but I want to know what folks think of where I'm at.

Rails form helpers (form_with) are useful and should continue to be used - they do the work when it comes to sorting out attribute names and make it much easier to build a form that sends parameters that your controller can work with. I don't think we should build components specifically to replace form builders - form builders should render components.

As I'm building a form field component, I'm using the _tag helpers such as text_field_tag, as they work in isolation from a form builder. If you built a field with a specific purpose (e.g. tags with autocomplete), you could use it in a form that's using a form builder without that component needing to depend on a form builder object as in @dkniffin's proposal.

This characteristic is a double-edged sword - _tag helpers can be mixed with form builder methods, so I can use this component in a form that's otherwise using a form builder. But using these helpers directly in the view means that I don't get the benefits of the form builder - in our case, that's default styling for the form field.

I think the goal is that you'd never use _tag helpers directly in the view again, and either render a form with a builder (which renders components), or render the form field component directly.

The trouble with making a component per field type is that there are some 20 different helpers, each with an API that the developer needs to define to their own tastes. In our case, we'd want to cover all the available attributes, perhaps set defaults, and add validations. It's a pretty big task, and we've already devoted six weeks to turning as much of our partials and styled elements into components.

TL;DR Rendering components from within a form builder as @pinzonjulian suggested is definitely the goal, but reflecting the sheer number of field types in a component library you'll need to maintain is the part that's heavy lifting.

[boardfish]

Since this thread still seems to get some eyes on it, view_component-form helps with this approach.

[pinzonjulian]

I've been working on this problem lately and I have some new information to share with everyone.

First, there is now a PR #946 documenting the usage of forms with View Component that encourages users to keep using the FormBuilder as the entry point for forms.

Second, I've understood some things even deeper now about Rails and forms that will help us shape the path for forms in View Component.

Why do we need ViewComponent in forms?

@swanson mentioned the following:

If you want to make ViewComponents for visual parts of a form (a Card or an InputGroup or a Banner) that will work fine, but in my opinion avoid replacing text inputs, selects, buttons, link_to, etc.

To some extent, you are right. Rails already has a way to abstract inputs and we shouldn't be reinventing that. The DSL to interact with Rails forms shouldn't change because it's great already. However, the way to build more complex input types does need a refresh.

The example we'll use throughout this post

Let's imagine we want to build a text field that looks like this:

This input field as a component would be composed of:

• Label
• Leading icon
• Trailing icon
• Error message
  • Conditional styles based on the error being present
• Hint text present in place of the error message before validation.

Current state: writing html in a FormBuilder is hard

If you want to replicate the previous example you're going to have a hard time doing it in a form builder method. The way to write html inside a FormBuilder looks something like this:
I'm not trying to replicate the example above because it's too complex

class MyCustomFormBuilder < ActionView::Helpers::FormBuilder
  def text_field(method, **args)
    @template.capture do
      @template.concat super(attribute, args.merge(class: 'a long string of classes if you use tailwind'))
        if some_var = args.fetch(:some_argument, nil)
          @template.concat @template.content_tag(:p, some_var., class: 'another long string of classes')
        end
      end  
  end
end

You need to know about:

• @template
• concat to return multiple tags in a block
• capture

And the cons of this:

• No default way to test them
• No way to preview them

How does Rails build a form input?

Here's where things become interesting. Rails shines when building forms if you use an ActiveModel::Model or an ActiveRecord because it abstracts from you things like tag attributes, tag ids, tag names etc. All of this lives inside ActionView::Helpers::FormHelper class and ActionView::Helpers::Tags module. Let's see how those work.

For a model Post you'd use the following syntax:

<%= form_with(model: @post) do |form| %>
  <%= form.text_field :body %>
<% end %>

If we dive into the code for text_field we'll find the following:

# action_view/helpers/form_helper.rb:1151
# ActionView::Helpers::FormHelper#text_field

def text_field(object_name, method, options = {})
  Tags::TextField.new(object_name, method, self, options).render
end

Note that self is the instance of the FormBuilder class used to render the form. In other terms, is the form object yielded to the block in the html.erb file. This is important because it demonstrates the dependency of an FormBuilder instance to be able to render html for a form.

Here's our first clue: Rails has objects that render views! (I always love seeing this because Rails has had components all along ❤️. Just abstracted through helpers like text_field.)

Let's dive into that object:

# action_view/helpers/tags/text_field.rb
# ActionView::Helpers::Tags::TextField

module ActionView
  module Helpers
    module Tags # :nodoc:
      class TextField < Base # :nodoc:
        include Placeholderable

        def render
          options = @options.stringify_keys
          options["size"] = options["maxlength"] unless options.key?("size")
          options["type"] ||= field_type
          options["value"] = options.fetch("value") { value_before_type_cast } unless field_type == "file"
          add_default_name_and_id(options)
          tag("input", options)
        end

        # some more code...
    end
  end
end

There's several important things to note about this file:

1. It uses :nodoc: which in the Rails codebase means: Private API.
2. Like all of Rails' codebase, this object inherits from a Base tag object that has most of the logic needed to render this type of tag.
3. The render method has two responsibilities
   1. set options
   2. render the html using the tag method

The important thing about this is that at the end, this class returns a fully formed input field of type text with all the options and the value (if present).

How would this look as a View Component?

Let's take a little step back and think of this from the developer experience. What would we want to use to create our form inputs?

First, we'd need a View Component. In order to make this component easy to test, preview and use in things like Storybook, we don't want it to depend on any other objects. In this case, we want to avoid any dependencies with FormBuilder. A simple version would look like this:

class ExampleDesignSystem::Forms::CompleteTextField < ExampleDesignSystem::Base # I'm making this up
  def initialize(label_attributes: {}, input_attributes: {}, error_message: nil, hint_text: nil, trailing_icon_name: nil, leading_icon_name: nil,)
    #...
  end
end

And we would use it in a form builder like so:

class MyCustomFormBuilder < ActionView::Helpers::FormBuilder
  def complete_text_field(method, **args)
    @template.render ExampleDesignSystem::Forms::CompleteTextField.new(
      label_attributes: label_attributes, 
      input_attributes: input_attributes,
      error_message: error_message,
      leading_icon_name: 'heart'
    )
  end
end

The missing piece now is, how do we extract the label and input attributes that Rails already knows how to create (which we saw an example of in ActionView::Helpers::Tags::TextField) ?

Proposed Solution

Remember that one of the findings of ActionView::Helpers::Tags::TextField was that it has two responsibilities? I think this might be the place where we can leverage Rails. By splitting the responsibility of this class we might be able to use the attribute building part without the rendering.

I imagine us being able to use something like this:

1. Modify Rails' tags classes to split rendering from building attributes

# action_view/helpers/tags/text_field.rb
# ActionView::Helpers::Tags::TextField

module ActionView
  module Helpers
    module Tags # :nodoc:
      class TextField < Base # :nodoc:
        include Placeholderable
        
        # the name and implementation of this method is just an example
        # the output of this method is a hash of key/value pairs with 
        # all attributes used by an input field of type text
        def complete_attributes
          @complete_attributes = @options.stringify_keys
          @complete_attributes["size"] = # ...
          # ...
        end

        def render
          tag("input", @complete_attributes)
        end

        # some more code...
    end
  end
end

Use an instance of that class and call the complete_attributes method to extract only the hash of attributes without the rendered html

class MyCustomFormBuilder < ActionView::Helpers::FormBuilder
  def complete_text_field(method, **args)
    # these can even be abstracted to helper methods like label_complete_attributes(...) and text_input_complete_attributes(...)
    label_attributes = ActionView::Helpers::Tags::TextField.new(...).complete_attributes
    input_attributes = ActionView::Helpers::Tags::Label.new(...).complete_attributes
    @template.render ExampleDesignSystem::Forms::CompleteTextField.new(
      label_attributes: label_attributes, 
      input_attributes: input_attributes,
      error_message: error_message,
      leading_icon_name: 'heart'
    )
  end
end

And then we build our component with those classes!

Currently I've mokeypatched ActionView::Helpers::Tags::TextField by wrapping it in a new class to be able to write this complete_attributes method. It's not pretty but it does the job.

Advantages

What I like about this approach is that it basically does exactly what Rails does: it delegates the responsibility of building the HTML to a more powerful object which, in our case, is a ViewComponent.

We also get the benefit of:

• Testing form inputs
• Previewing form inputs using default previews
• Previewing using Storybook (which makes more evident the need for the View Component to be dependent on primitives only)
• Allowing to easily add interactivity using Stimulus JS and View Component sidecar asset to create more complex input types (like chips)

State of the art

While writing this post I remembered a gem that uses View Component to wrap the Material Design spec and it actually does something very similar to what I'm outlining here. Please take look!

https://github.com/fernandes/arara
https://github.com/fernandes/arara/blob/master/app/components/arara/form_builder.rb
https://github.com/fernandes/arara/blob/master/app/components/arara/tags/text_field.rb

What is required to do this

It's important to remember that I'm using a private Rails API to do this which means that for this idea to see the light of day, we would need to coordinate with the Rails core team to understand why this API is private and how could we open it to leverage its power to do this.

The End!

Please let me know what you think about this idea. It's my latest iteration into integrating View Component with forms in the most organic way possible.

[xkraty]

I've had the same issue and right now I'm testing out a new solution it came to my mind after reading all the guys suggestions here.

As stated by @pinzonjulian if you need something easy the capture is fine but if you need something more complex a component would perfectly fit the needs.

My Requirements

My requirements was to have a field looking like this one

My Goal

My goal was to let the people of my team manage forms with the rails syntax they are used to like f.text_field :name and to delegate the problem of the style to the frontend developer.

The issue

The main issue with other solutions was that it had a wrong field name, I ended up in understanding that I'm just fine with the rails generated input field, I just want it to have my custom classes and be wrapped in some others div for styling purpose.

Solution

I've disabled the field_with_errors field generated by rails and by thinking that I wanna use both rails inputs both view components I've created a slot for the input field and passing it the super by adding my custom classes to the super options.

# app/form/dashero_form_builder.rb
class DasheroFormBuilder < ActionView::Helpers::FormBuilder
  def text_field(attribute, options = {})
    icons = { before: nil, after: nil }
    icons = icons.merge(options[:icons]) if options.key?(:icons)

    @template.render ::Input::Text.new(object: @object, attribute: attribute, **icons) do |component|
      component.field do
        super(
          attribute,
          objectify_options(
            options.merge({ class: component.classes })
          )
        )
      end

      yield(component) if block_given?
    end
  end

# app/components/input/text.rb
class Input::Text < ApplicationComponent
  renders_one :field
  renders_one :before
  renders_one :after

  attr_accessor :object, :attribute, :before_icon, :after_icon

  def initialize(object:, attribute:, before: nil, after: nil)
    self.object = object
    self.attribute = attribute
    self.before_icon = before
    self.after_icon = after

    super
  end

  def classes
    %w[my-tailwind-classes]
  end

  def label_classes
    %w[my-tailwind-class, ('my-additional-error-classes' if errors)]
  end

  def errors
    object.errors[attribute].presence
  end
end

/ app/components/input/text.html.slim
label class=label_classes
  .mr-2.text-gray-700
    = before
    - unless before_icon.nil?
      = render ::Unicons::Icon.new(icon: before_icon)

  = field
  .ml-2.text-gray-700
    = after
    - unless after_icon.nil?
      = render ::Unicons::Icon.new(icon: after_icon)

- if errors
  p.text-red.mt-2
    = errors.join(', ')

So this can be used like this:

• text field with no icons

 = f.label :name
 = f.text_field :name, placeholder: true

• text field with icons

 = f.label :name
 = f.text_field :name, placeholder: true, icons: { before: 'icon-name', after: 'icon-name' }

• text field with a block

 = f.label :name![bitmoji](https://sdk.bitmoji.com/render/panel/9d9f5e18-ccc2-49a8-92e5-5196b1caad81-63b1b291-470d-4d65-b249-682c592fa363-v1.png?transparent=1&palette=1&width=246)
 = f.text_field :name, placeholder: true do |component|
   - component.after do
      button ...
   - component.before do
     = link_to ...

NOTE: ::Unicons::Icon is just another component of mine which simply render the svg icon

Thoughts

This is looking good to me cause I'm just extending form builder to use View Component with the usual input field and you still can use the default rails form builder if needed, please let me know what you think about!

[boardfish]

This seems like a strong improvement on @pinzonjulian's solution that doesn't need to go below the surface of Rails form helpers. Being able to use slots is a nice bonus!

[pinzonjulian]

Thanks for posting this!

Different from your solution @xkraty , what I'm aiming for is to have a component which does not depend on an instance of the form builder but only on primitives (strings, integers, hashes of primitives etc).

Having your component accept an object makes testing and the usage of things like storybook to document the component very hard.

@boardfish I actually feel it's not something I'd judge in terms of improvement but in terms of scalability. To me, the act of standardising form inputs has several steps ranging from least complex (easy to implement but harder to maintain and test) to more complex (harder to implement but easier to maintain and test). I think all options are valid depending on your team size, project size and scope, project needs.

These are the options I see when building form inputs in Rails.

1. Doing it with css classes in your templates form.text_field :name, class: 'form-input'
2. Abstracting styling in a form builder method using content_tag capture & concat (no component)
3. Abstracting styling in a form builder method with a ViewComponent that's dependent on FormBuilder (your solution)
4. Abstracting styling in a form builder method with a ViewComponent with no dependencies on any objects (my solution)

[pinzonjulian]

Another thing to note is that your component is a Input::Text which actually has no markup for the input field itself because it is a dependency you inject as a slot so it's actually possible to create a Input::Text field with no <input type="text"> tag which seems a bit odd

[xkraty]

@pinzonjulian I totally agree with you, this is just the best workaround I could apply in my case. I'm really loving View Component and I'd like to see them to be working natively in Rails without having to manually patch files or whatever.

[Spone]

Thanks a lot for sharing your thoughts and approaches here!
I'd like to share the approach we're currently exploring, @nicolas-brousse & I.

The idea is to create a FormBuilder (as a gem) that will have the same interface as ActionView::Helpers::FormBuilder, but use ViewComponents for rendering all kinds of fields. To get started quickly, all you would have to do is add a builder param to your form_for or form_with:

- <%= form_for @user do |f| %>
+ <%= form_for @user, builder: ViewComponent::Form::Builder do |f| %>

You can also define a default FormBuilder at the controller level using default_form_builder.

Then call your helpers as usual:

<%# app/views/users/_form.html.erb %>
<%= form_for @user, builder: ViewComponent::Form::Builder do |f| %>
  <%= f.label :first_name %>        <%# renders a ViewComponent::Form::LabelComponent %>
  <%= f.text_field :first_name %>   <%# renders a ViewComponent::Form::TextFieldComponent %>

  <%= f.label :last_name %>         <%# renders a ViewComponent::Form::LabelComponent %>
  <%= f.text_field :last_name %>    <%# renders a ViewComponent::Form::TextFieldComponent %>

  <%= f.label :email %>             <%# renders a ViewComponent::Form::LabelComponent %>
  <%= f.email_field :email %>       <%# renders a ViewComponent::Form::EmailFieldComponent %>

  <%= f.label :password %>          <%# renders a ViewComponent::Form::LabelComponent %>
  <%= f.password_field :password %> <%# renders a ViewComponent::Form::PasswordFieldComponent %>
<% end %>

This would work out of the box. Then you can subclass the provided FormBuilder and override some of the ViewComponents to customize their rendering, add CSS and JS. Generators could be included to help with this step.

Later, the gem could include another "advanced" FormBuilder including more components, to handle common use cases:

• displaying all errors at the top of the form
• displaying errors below each field
• "grouping" the label, field, hint and error messages in a single component (similar to @pinzonjulian & @xkraty examples)
• interactive nested fields à la Cocoon

You could end up with something along those lines:

<%# app/views/users/_form.html.erb %>
<%= form_for @user, builder: CustomFormBuilder do |f| %>
  <%= f.errors %>

  <%# renders a ViewComponent::Form::GroupComponent
      that takes a block, prefixes it with a label
      and renders errors below %>
  <%= f.group :first_name, hint: "How should we call you?" do %>
    <%= f.text_field :first_name %>  <%# renders a ViewComponent::Form::TextFieldComponent %>
  <% end %>

  <%# ... %>
<% end %>

Overall, this approach is very similar to what @xkraty describes above. It aims at being a good starting point for anyone who wants to replicate this approach without writing a ton of boilerplate :)

We're actually extracting code from an app that is already running in production. We started working on it here: view_component-form but it's still very early. I'll keep you posted in case some of you are interested in trying it out!

[Spone]

We just pre-released the v0.1.0 of view_component-form. If some of you have time to try it out, we would love to hear your feedback!