-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#59: Add Fieldset component #60
Conversation
|
Preview URLsGH Env: preview |
c3ab9f1
to
626d095
Compare
626d095
to
4bcda86
Compare
> | ||
<p class='text-body-and-labels text-xs m-0 italic'>~Fieldset components render | ||
here!~</p> | ||
</Form::Fieldset> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Essentially how some of this will look with the checkbox group is:
<Form::Fieldset
@label='Label'
@hint='Extra information about the fieldset'
@error='Error message'
>
<Form::CheckboxField @label='Label1' name="label1" />
<Form::CheckboxField @label='Label2' name="label2" />
<Form::CheckboxField @label='Label3' name="label3" />
</Form::Fieldset>
Maybe I should render this instead of the <p>
tag? I was hoping to convey this can be used as a generic fieldset component, but I'm not sure which is better for an example! Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A demo for checkboxes and radios (maybe as a follow up) would be great! It seems like the most common use case from what you mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait...do we only get one demo per component? If think so...if so yeah ^^ I would make those changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the default docfy setup (which this is closer to, as opposed to the CS-internal docfy usage), additional demos are appended on the page vertically -- example here: https://docfy.dev/docs/ember/components/docfy-previous-and-next-page
folder for the demos here: https://github.com/josemarluedke/docfy/tree/main/packages/ember/docs/components/docfy-previous-and-next-page-demo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also appreciate a checkbox demo, however the default should IMHO be as-is, to not confuse users about the different concerns of these components.
This PR should make our use of demos more flexible: josemarluedke/docfy#152
> | ||
<p class='text-body-and-labels text-xs m-0 italic'>~Fieldset components render | ||
here!~</p> | ||
</Form::Fieldset> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also appreciate a checkbox demo, however the default should IMHO be as-is, to not confuse users about the different concerns of these components.
This PR should make our use of demos more flexible: josemarluedke/docfy#152
<Fieldset @label="Label" @isDisabled={{true}} data-fieldset /> | ||
</template>); | ||
|
||
assert.dom('[data-fieldset]').isDisabled(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine. But I believe this will only prevent any inputs submitting their value for "normal" forms not handled by JS. For this PR it doesn't matter, as these atoms here don't handle forms or form submissions at all. But at the form level we need to make sure this works as expected. Created this for headless: CrowdStrike/ember-headless-form#73
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great to me. Thanks a bunch for filing that!
|
||
## Label | ||
|
||
Provide a string to `@label` to render the text into the `<legend>` of the Fieldset. This is required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there might be use cases where you would want to not have a label, or rather have the label be visually hidden (but present for screen readers)?
If so, does not need to be as part of this PR, can still add this later if needed...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally! I think we will definitely need this quite soon for all form components. Went ahead and filed #62
Think a @isLabelHidden
argument would do? Maybe a different name? Or maybe a different way to solve this completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agree, something like that! I would still make @label
mandatory, to enforce a11y.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to enforce a11y.
Oh absolutely! Nice!
🚀 Description
This PR introduces a
Fieldset
component so we can build checkbox and radio groups.NOTE: These components are not 100% styled yet, as we are still figuring out where to land on a few things. This is about ~75% close though.
Closes #59
🔬 How to Test
📸 Images/Videos of Functionality
a11y
Show how the screenreader picks up on the hint + error text
fieldset-a11y.mov