Clarity: Generic form containers for non-input elements and for custom Angular components.

[whizkidwwe1217]

Summary

Angular Form Input Controls

1. Allow non-input elements such as h1, h2, span, etc. to be laid out nicely with labels in the standard clarity form design.
2. Containers or wrappers for custom components in forms.

Use case

1. Non-input element/static content
There are some fields in a form that don't need an input from the user and the purpose of those fields is just to display read-only or system generated texts. These static contents needs to be laid out properly in the form just like how the labels are aligned and the existing supported input controls are being laid out in the form.

2. Custom components
Right now, only those input controls that have supported input directives like clrInput are supproted by Clarity. Without a directive, the control will not be displayed in the form. I should be able to display a custom component. For example, a rich text editor component.

Examples

_Are there any examples in other projects that demonstrate this feature or enhancement?_
Non-input components
clr-input-container does not display an Angular component or an HTML element inside it if it doesn't have an input directive.
Example:

<clr-input-container>
    <label>Custom Component:</label>
    <span>INV-0002-200395</span>
</clr-input-container>

or

<clr-input-container>
    <label>Custom Component:</label>
    <my-custom-component></my-custom-component>
</clr-input-container>

Tried without clr-input-container but labels and components are not laid out and formatted properly.

Custom components

Workarounds

_Is there a workaround for this feature at the moment, even if it is less than ideal?_
I'm currently using the Clarity forms for Angular. Maybe a combination of angular & Clarity's css for forms

[Jinnie]

I believe this duplicates #2864
I won't be directly closing it, please review and comment if the approach discussed there will suit your needs.

[gnomeontherun]

Thank you for the well written request, this is useful for helping understand the use cases.

As a workaround, you could use the HTML and build the same DOM structure, but there could still be edge cases and some CSS to apply to make things look exactly as you wish. This is definitely something we need to look into handling, but since this one is more detailed I'm going to mark the other as a duplicate and close it in favor of this one.

[paddyfink]

Hello,
I haven't tried it out but does that mean that I cannot use for example kendo ui component inside clr-input-container?

[gnomeontherun]

@paddyfink No you cannot, because they don't wire up the internals like we do. However, you could use the HTML/CSS version (the bottom part of the documentation for inputs for example) and replace the input with a third party component. There might be some styling issues to address for it to layout properly though.

[paddyfink]

Ok Thanks @gnomeontherun. I will give it a try.

[rbirkgit]

This one is important. Even having a simple container object that doesn't support validation etc would be very useful.

[dennitsa]

I was planning on opening a new request, but perhaps I should just add our use case here.
It would be nice to be able to add extra content inside an input element(or select, checkbox and so on).
E.g. we have inputs that require the user to type in minutes and we want to have the text "minutes" right after the input field. Using helper text is not an option in this case, as it is already filled with info explaining the purpose of the input field.
E.g. we would like to be able to have something like this:

Also using elements such as a singpost after the input is something we have in our existing UI:

Currently the only option is to move the signpost content inside the helper field, but our UX has concerns with this approach, especially for longer texts.

[dorthrithil]

@dennitsa Input groups are probably what you are looking for. There's already a separate issue for this: https://github.com/vmware/clarity/issues/1478

[dennitsa]

@dennitsa Input groups are probably what you are looking for. There's already a separate issue for this: #1478

As far as I can see the other issue hasn't been considered in Clarity 2.0+ either. Anyway, whether it is a custom component or a standard input with extra custom content next to it, I think the use case is quite similar.

[rbirkgit]

We have a lot of custom components (and also use many signposts), and this is one of the major hurdles for us upgrading to the new forms.

[gnomeontherun]

I've investigated this before, and the custom styling present in many third party components makes this pretty difficult, if not impossible. There is likely to be a manual styling overrides required depending on what the control is and how it displays. We can work on a scaffolding for a starting point, but making it seamless is very unlikely.

[whizkidwwe1217]

I was able to make custom form controls and was able to make them work as if they are part of the pre-built Clarity forms. I created custom form controls and custom input containers. They respond very nicely with Clarity form's layout services, validations indicators, etc. The workaround is to copy all the required services and utility classes since Clarity doesn't expose these to the public. I just changed the filenames but kept the component/directive selectors unchanged. This allows me to trick Angular as if they are Clarity's. The only drawback that I can currently think of is that I have to keep this in-synced with the original code every time Clarity updates the library. Also, I'm not sure if there are adverse effects of doing this type of workaround.

_Sample custom search component_

[rbirkgit]

whizkidwwe1217, this is interesting and something we would like to use (and need) when some day we switch to the 2.0 forms.

[github-actions[bot]]

Hi there 👋, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.