Simple Form VS Cocoon

I also tend to use gems like simple_form to generate my form HTML, and this saves me from having to maintain a lot of view code to outputting translated content onto forms. Also simple_form has it's own i18n convention that compliments the Rails default pretty well.

I followed the RailsCasts tutorial and its GitHub page to set up the gem in my application and used it for all of the models in my application. It was working perfectly fine showing the default error message at the top and the validation message at the bottom of their respective fields.

Okay now for those "buttons". We don't want just a normal button or link though. This is where we need the booking update form. Let's use simple_form_for (check out the docs here).

There are many ways to create a form in Rails, whether you want to create a form with Form builder from Rails itself or maybe using third party gem like simple_form. Of course, simple_form is not the only option we have to build form in rails, there are alternatives out there such as formtastic, cocoon, nested_form, etc. However, in this post I'm going to give you a basic use case to use simple_form in Rails application.

I usually go with simple_form, I customise my forms by configuring it and letting it handle the repeated rendering.

Simple Form gem

The biggest unclear area that we saw related to view components were forms. There were glimpses of compatibility issues with Rails form helpers in the documentation and we saw a recent effort of the team to mitigate them. Moreover, we were used to building forms with Simple Form which added another variable to the equation. And, in general, we considered the Rails form builders (as well as the Simple Form builder) a system of form-related components in the first place so we were unsure how this would fit into the View Components ecosystem or whether we should even try to do that.

Learn more about simple form: 1) https://github.com/heartcombo/simple_form 2) https://www.youtube.com/watch?v=NfZk74R2Oi4&t=5s

Nested forms are forms that handle nested models and attributes in one form; e.g. a project with its tasks or an invoice with its line items. Before Rails 6, Cocoon is a good choice for creating dynamic nested forms. But Cocoon needs jQuery to work well, it's a very old library on modern-day frontend frameworks. When Stimulus is came out, Rails devs is suggested to use Stimulus as Javascript library in their projects. So, I created a gem for handling dynamic nested forms with Stimulus JS.

On a previous project I used Cocoon which makes it simple to add a button that adds an additional set of fields for a nested object.

You can use the Cocoon gem to have nested stuff that can be all posted back at once and update multiple related tables. Necessary setup includes on the models having appropriate accepts_nested_attributes_for entries for the various has_many associations that would link to your sub-forms.

Prior to the advent of Turbo and Stimulus, my go-to for creating dynamic nested forms was Cocoon which has been around a while and uses jQuery. Tried and true.

The Cocoon Gem does something similar, it allows to easily add associated resources to an object. But can it allow creation of other object within the form of another object ?

For dynamic forms my usual go-to is Cocoon. https://github.com/nathanvda/cocoon

To add and remove recipe ingredients, we're going to use my favorite gem for handling this. The gem is called cocoon. Cocoon defines two helper methods, link_to_add_association and link_to_remove_association, these are aptly named because what they do is provide links that, when clicked, will either build a new association and create the appropriate fields or will create a link with the ability to mark an association for deletion.