CustomField - New web-component for creating field options

[colemanw]

Overview

New widget for adding options while creating a custom field.

Before

Old quickform-based widget was limited to adding 10 options.

After

• Unlimited options
• Draggable sorting
• Can be auto-sorted alphabetically
• Reusable widget could also be useful for price sets, etc.

Technical Details

• This creates the first general-use web component for CIvi core forms.
• See elements@1 - Auto-load custom-elements (web-components) from extensions #34348 for auto-loading discussion.

[civibot]

🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷

Introduction for new contributors...

• If this is your first PR, an admin will greenlight automated testing with the command ok to test or add to whitelist.
• A series of tests will automatically run. You can see the results at the bottom of this page (if there are any problems, it will include a link to see what went wrong).
• A demo site will be built where anyone can try out a version of CiviCRM that includes your changes.
• If this process needs to be repeated, an admin will issue the command test this please to rerun tests and build a new demo site.
• Before this PR can be merged, it needs to be reviewed. Please keep in mind that reviewers are volunteers, and their response time can vary from a few hours to a few weeks depending on their availability and their knowledge of this particular part of CiviCRM.
• A great way to speed up this process is to "trade reviews" with someone - find an open PR that you feel able to review, and leave a comment like "I'm reviewing this now, could you please review mine?" (include a link to yours). You don't have to wait for a response to get started (and you don't have to stop at one!) the more you review, the faster this process goes for everyone 😄
• To ensure that you are credited properly in the final release notes, please add yourself to contributor-key.yml
• For more information about contributing, see CONTRIBUTING.md.

Quick links for reviewers...

• ➡️ PR Demo site (can be rebuilt with the command test this please).
• 📖 Review standards
• 🗒️ Review template (brief or verbose)

➡️ Online demo of this PR 🔗

[ufundo]

Looks cool @colemanw - definitely a good use case :)

Easy thoughts:

• I've been using the civi- namespace for the components I've done so far. It seems a nice way to distinguish from angular components
• I've been using the exact tag name for the filename - e.g. civi-my-component.js. I think that's the scheme that elements@1 - Auto-load custom-elements (web-components) from extensions #34348 expects

Hard thought:

• I think the component should encompass it's internal template, rather than rely on it being in the smarty template. Ie something like this ufundo@83bfe0b
• the particularly hard part of that is translation. so far I've used things like

this.innerHTML = `<label></label><input type="text" />`;
this.querySelector('label').innerText = ts('My Label')`

but it's a bit of a faff.

I've got two ideas for translation currently: [moving this bit to https://github.com//pull/34348 as its a better place to discuss ]

[colemanw]

@ufundo good feedback. I agree with your easy thoughts & will fix that when #34348 stabilizes. We should probably hold off on merging this until that one is finalized so this can use the autoloader.

I actually don't agree about the template. Not including the template as part of the element has 4 advantages:

• Flexible data structure (biggest advantage) – this widget provides repeatability and sortability of rows but it has no opinion re the contents. This allows it to be reused in other forms e.g. price sets, simply by passing in a table with different columns.
• Flexible markup – should we be using bootstrap3 classes, classic civi classes, or something else? This way we're not locked into any decision.
• Flexible layout – where should the "add" button go, and what text/icon should it contain? What should the headers say? How should each column be styled? All totally configurable.
• Config options – Which columns should be sortable? Should drag-n-drop sorting be enabled? Which fields auto-increment? This is all set in the markup.

In short, hard-coding the template kills reusability of the widget. To keep reusability, you'd have to abstract the template into all the above-mentioned config options (a couple dozen of them if you count everything I just mentioned above!). So then to use this element you'd have to pass those dozens of config options in... but by the time you get done writing out all those config options... why not just write markup? It's so much more readable to designers, themers, etc.