This repository was archived by the owner on Jan 20, 2022. It is now read-only.
forked from Semantic-Org/Semantic-UI-React
-
Notifications
You must be signed in to change notification settings - Fork 2
docs: add glossary to specifications #71
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,85 @@ | ||
| #Stardust Glossary | ||
|
|
||
| ##Component anatomy | ||
| ###Types | ||
| Types are versions of an element that modify the element's standard appearance. | ||
|
|
||
| Types cannot be used simultaneously on the same element. For example, "cats" and "dogs" are types of animals, but are mutually exclusive. | ||
|
|
||
| <b>Comment</b>: We should use types for defining the standard appearance of the component. What we have so far is using the primary and secondary as types, which in my opinion are variations of the component that are only between themselves mutually exclusive. So, we can define those as enum variation of the component, but sadly we so far come up with the name 'type' for the prop that can be confusing. I propose we change the name of this prop with something like suiStyle (bootstrap has something similar – bsStyle). Should we add here the positive and negative props as well? After this we can use one prop with enum for defining all different types of the component (similar in a way of the shape property in the current [Menu component](https://github.com/stardust-ui/stardust/pull/68) | ||
|
|
||
| ###State | ||
| States are modifications to an element that help indicate a change in [affordance](http://www.usabilityfirst.com/glossary/affordance/). Common states include loading, disabled, and active. | ||
|
|
||
| ###Content | ||
| Content are parts which only have meaning in the context of a component. Content use names which describe the type of expected content like header, description, menu, or item. | ||
|
|
||
| Content inside a collection or view often includes stubbed versions of other components. For example cards let you use image content, which can be extended by using different variations. | ||
|
|
||
| ###Variations | ||
| Variations modify qualities of an element like size or color. | ||
|
|
||
| Variations are mutually inclusive, and can be used together to modify an element. | ||
|
|
||
| ##API Design | ||
| ###Top Level API | ||
| ####Components | ||
| A component is a general term used to refer to any user interface element packaged for distribution (Not to be confused with React’s Component) | ||
| ####Shorthand/Children definition | ||
| Most of the components support two ways of definition: shorthand and children. With the shorthand definition we are adding some props to the component in order to define it’s content, in opposite to the children where we are adding the content inside the component, or using some subcomponent. For example: when defining the text displayed in the Button component, we can pass the content prop or we can define the text inside the component: | ||
| ```html | ||
| <Button>Click me!</Button> | ||
| <Button content='Click me!' /> | ||
| ``` | ||
| ####Subcomponents | ||
| Some of the components have subcomponents defined for passing JSX elements for special parts of the component. For example the Menu components can contain multiple items inside, that can be defined using the Item subcomponent in the following manner: | ||
| ```html | ||
| <Menu> | ||
| <Menu.Item active={activeItem === 'a'} onClick={this.handleItemClick('a')}> | ||
| Editorials | ||
| </Menu.Item> | ||
| <Menu.Item active={activeItem === 'b'} onClick={this.handleItemClick('b')}> | ||
| Reviews | ||
| </Menu.Item> | ||
| <Menu.Item active={activeItem === 'c'} onClick={this.handleItemClick('c')}> | ||
| Upcoming Events | ||
| </Menu.Item> | ||
| </Menu> | ||
| ``` | ||
| ###Props API | ||
| ####Enum | ||
| We use enum for properties when multiple values are mutually exclusive. We should use the same enums defining the same props across all components for consistency. | ||
|
|
||
| ####Boolean | ||
| We use boolean for properties when multiple values are mutually inclusive and don’t need any description. This way we are only implying that that property is applied to the component. | ||
|
|
||
| ##Design language | ||
|
|
||
| |Term|Description| | ||
| --- | --- | ||
| type: primary | Used to emphasize a componet's appearance and catch user's attention. | ||
| type: secondary | Used to de-emphasize a component's appearance. | ||
| type: positive ? | Used to hint towards a positive consequence. | ||
| type: negative ? | Used to hint towards a negative consequence. | ||
| children | The primary content of the component. | ||
| content | Shorthand for primary content. | ||
| as | An element type to render as, that can be a function or string. | ||
| className | Additional classes that will be applied to the component. | ||
| size | Used to define different sizes of the component. Comment: Should be standize across all components with values from 0 to 10 for example. | ||
| role | The role of the HTML element generated by the component. | ||
| color | Used for defining specific color for the component, by selecting one of the SUI colors enum. | ||
| inverted | Used to format the component to appear on dark background. | ||
| basic | Used for the component to be less pronounced. | ||
| floated | Used for the component to be aligned to the left or right of its container. ('left', 'right') | ||
| active | Used to style the component showing that it is the current user selection. | ||
| disabled | Used to imply that the component is currently unable to be interacted with. | ||
| loading | Used to make the component show some loading indicator. | ||
| icon | Add an Icon by name, props object, or pass an <Icon />. | ||
| label | Add a Label by text, props object, or pass a <Label />. | ||
| attached | Used for attaching the component to some component. ('left', 'right', 'top', 'bottom') | ||
| compact | Used to make the component take up only the space necessary to fit its content. | ||
| fluid | Used to make the component takes the width from the parent. | ||
| fixed | Used to make the component fixed to a side of it's content. ('left', 'right', 'top', 'bottom') | ||
| textAlign | Align the content. ('left', 'right', 'center', 'justified') | ||
| vertical | Used to make the component display it's content vertically. | ||
| shape | Used to describe the shape of the component. For example for the Menu component, beside the default, we have the following shapes: ('pills', 'pointing', 'underlined') | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm adding a new property to the buttons that have icons, called
<Button icon="book" iconPosition="right" content="click" /> |
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 added here comment about whether we should replace the type property with something like suiStyle, for setting the primary, secondary, positive or negative variations of the components. Now that we have introduced the shape property, we can still stick with the type property as initially. We should decide on this and I will change the description accordingly.
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.
my opinion on that is that
typeis a much pleasant name in contrast tosuiStyle- while the later one seems more specific, the problem is that it is not as intuitive for the client as the first one. It would be really hard for the client to remember it in a way to not use docs as a refresherThere 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.
with that being said, would rather suggest to apply
primaryandsecondaryas props, even given that they do not fit common logic so far. Another option is to come up with another property name that is not library specific (is close to the general notion), likekindor something like thatThere 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 am definitely for having one prop with different values for the
primary,secondary,positiveandnegative, as a hint to the user that these cannot be applied at the same time. And yes, I agree that we should come up with a good name, as this is one of the props which will be most commonly used. @levithomason any thoughts on this?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 propose we merge this PR as is now. In the glossary table this property is described as
type, which is the current implementation, and we can update it later if we think it would be appropriate. All other PRs should update this table if they are introducing new props, and we still don't have this merged on the master which can become a problem. @kuzhelov ?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.
agree, it could work as long as we won't introduce another possible types for components (that could be applied at the same time with primary or secondary). At this point we could rethink this taken approach