Add code examples for ts_form_for components

[slhinyc]

• Add ts_form_for code examples to all examples that can be rendered with ts_form_for, for these components:
  • sl-checkbox-group
  • sl-checkbox
  • sl-radio
  • sl-radio-group
  • sl-input
  • sl-select
  • sl-textarea
• Also fix related Slim code to be more readable
• Add note to Form Controls doc page that more ts_form_for documentation is coming, plus link to sample component example with ts_form_for code
• Plus misc:
  • Fix broken code example for sl-radio-button
  • Make code comment text color darker (to be more readable)

---

Note to reviewers

This is a docs-page only change, so I plan to just merge to next after approval and deploy to design.teamshares.com. No new release version would be needed for these changes.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
shoelace	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 4, 2024 11:25pm

[kdonovan]

I'm curious about this one -- usually Rails accepts either a two-element array or an array of explicit label/value tuples (to the extent that we rarely build the array manually, usually you'll do something like f.input :foo, collection: Model::OPTIONS or something).

Have we confirmed this three-element-array approach renders as expected?

[slhinyc]

Oohh TY for calling this out. I had tested this in the kitchen_sink_form and confirmed that everything rendered as expected, but just to be sure I also tried this out with a real form in os-app (the Cap Table Events form) and there was indeed an issue! Fortunately I think there is a simple fix?

Grouping the non-label/value attributes separately with curlies like so seemed to work, and as long as the label & value are kept :first and :last and any other array references are also updated accordingly, this form seemed to render & function as expected (I was able to fill out & submit the form locally):

 ADMIN_EVENT_TYPE_OPTIONS = [
    ["Issue shares", { description: "hello" }, "issue"],
    ["Employee buyback", { description: "hello", disabled: "true" },  "employee_buyback"],
    ["Teamshares buyback", {}, "teamshares_buyback"],
    ["Top up employee pool", {}, "topup"],
    ["Cancel a certificate", {}, "cancel"],
    ["Accelerate vesting", {}, "accelerate_vesting"],
    ["Preferred shares purchase", {}, "preferred_shares_purchase"],
  ].freeze

Does this approach seem okay?

[kdonovan]

@slhinyc I'm sorry for the back and forth here -- I don't think I've ever passed more than two elements in an array to a form helper, so it looked weird initially, but the simple_form docs say:

By default, Simple Form will use the first item from an array as the label and the second one as the value

And checking your kitchen sink form, it looks like [['Daily Updates', :daily, description: "Updates every day"], ['Weekly Newsletter', :weekly, description: "Updates every week"],['Monthly Digest', :monthly, description: "Updates every month"]] is working exactly as expected, so...

I would say I was completely wrong and to ignore that comment entirely, but it sounds like you're running into an issue in OS?

And confusingly, despite what the docs say, your example from above also seems to be working... ? 🤔

UPDATE: OK, so your example above does not completely work as expected -- in the screenshot you can see the value="hello" on the sl-radio-group, but the value="hello description" on the individual sl-radio element (confirmed it comes through to the controller as hello description).

tl;dr entirely my bad, I think we need to revert to what you had originally? But happy to pair later today to talk through whatever's going on in OS :)

[slhinyc]

no worries! i'm so glad you called this out!

so the form i tested in OS uses :last and :first to specify which element in the array to use as the label & which as the value. So it was picking up the "description" attribute as the :last or value element, and so I was also getting that strange value that you saw when you were testing in the kitchen sink form. But if you add label_method: :first, value_method: :last to the kitchen sink form, that should fix the weird value problem, because simple form now takes the first & last elements as label and value, & ignores the middle element? I just tried it in the kitchen sink & it seems to work:

= f.input :push_notifications_2, 
  as: :radio_buttons, collection: [
    ['Daily Updates', { description: "Updates every day" }, :daily],
    ['Weekly Newsletter', { description: "Updates every week" }, :weekly],
    ['Monthly Digest', { description: "Updates every month" }, :monthly]
  ],
  label_method: :first,
  value_method: :last,
  label: "Push notification preferences 2",
  wrapper_html: {"label-tooltip": "I'm a tooltip", contained: true, required: true }

So adding this extra hash for the description and disabled attributes will work as long as they are wrapped in {} and we either specify which elements in the array are the label & the value, or if using the Simple Form default, we make sure the extra hash is the third element in the array. I can add this note to the docs, too. But I think in general, this approach should work for passing these extra attributes to the array?

[kdonovan]

Ah! It'd be ideal to use the defaults wherever possible, so I think our best case would be to use your original pattern, and update that one form in OS to set value_method: :second rather than :last? (I think that'd require the least changes).

[slhinyc]

Made the code example & comment changes as we discussed earlier. Merging now!

[kdonovan]

Suggested change

	e.g. @cap_table_event = CapTableEvent.new(a: "issue_shares")
	e.g. if using `ts_form_for @cap_table_event`, set @cap_table_event = CapTableEvent.new(a: "issue_shares")

[slhinyc]

TY! Updated all the places where this comment appears!

[kdonovan]

Thank you for writing up all this documentation!! 🙏

One question with an example passing three-element arrays into collection that could be problematic, and a suggestion to tweak the "how to set initial value" comment... otherwise, LGTM!