-
Notifications
You must be signed in to change notification settings - Fork 23
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
Build slot demo library #3868
Comments
Adding Slot Demo Library Figma file |
5/29 updateNext steps + current checklistSlot component
Education
User testing
Component building
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Continue to work with slot component Create mini published library for proof of concept - with a few selected container components:
Card
Popover
Layer center
Use naming conventions & emoji, warnings on the thumbnail to indicate that its a DS test only published library.
@KennyAtHPE
For the library
Create an publish a test library
Populate with container components, using preferred slot method
Insert instanced into a second 'playground file' and share with team.
@luketa8
For the test components
Define the "container"anatomy via grommet, what is each component at its most basic -
What properties are handle at this “surface” (eg most container components are opinionated about radius, elevation, bg color, close button.
Everything else should be managed in subcomponent(s) -
Define where HPE theme has opinions
eg
Card HPE must have a semantic title, could have media.
Look to existing anatomy on DS site and consider how these rules & props can be built into the inner sub component.
eg
Popover - Must be dismissible
For these slot containers, what in HPE guidance would indicate if they should have multi slots (eg card footer)
Suggest names for a glossary as a staring point for guidance
1- Slot component (Im happy with slot )
2- Slot host component (container, wrapper, parent)
3- Swapped in component
Evaluating this should be based on
1- Does it make it easier for us to produce "container components" in future
2- Testing functionality - push changes to a component that has replaced a slot - what other tests are required
3- What is our decision on pre-configuring common use cases -
4- We will need to be comfortable allowing other team to use slots - do we document a usage agreement -
5- If we are using preferred slot for DS approved patterns, how to we educate and showcase usage outside of the DS library
The text was updated successfully, but these errors were encountered: