semantic-org / semantic-ui-react

The official Semantic-UI-React integration

Semantic UI React

Installation & Usage

See the Documentation for an introduction, usage information, and examples.

Built With

• Amazon Publishing — the full-service publisher of Amazon — APub.com
• Netflix's Edge Developer Experience team's numerous internal apps
• Netflix's flamescope
• Microsoft's Teams prototyping

Example Projects

This is a listing of example projects and guides that will help you integrate Semantic UI React into your new or existing projects.

Show projects

semantic-ui-react-todos

Semantic UI React implementation of react-redux Todo List.

FAQ

Can I use custom Icons?

Yes. Just use <Icon className='my-icon' /> instead of <Icon name='my-icon' />. See #931 (comment) for detailed info and examples.

How do I setup CSS?

There are several options. Refer to our doc on CSS Usage.

Can I use a custom CSS theme?

Yes. Semantic UI React includes components that render valid Semantic UI HTML, no CSS is included. This allows you to load any Semantic UI CSS theme on top of your Semantic UI React app.

Here are some helpful links:

• Building CSS with Webpack
• Building CSS with Meteor
• Creating a standalone theme

How Can I Help?

Voice Your Opinion

Help shape this library by weighing in on our RFC (request for comments) issues.

Contribute

Our CONTRIBUTING.md is a step-by-step setup and development guide.

Good First Issue

Issues labeled good first issue are a great way to ease into development on this project.

Missing Components

We're seeking component parity with Semantic UI, plus some addons. There is an issue for every missing component, labeled new component. Just comment on the issue you'd like to take.

Help Wanted Label

Any other issue labeled help wanted is ready for a PR.

Principles

• No animation dependencies
• Simple declarative component APIs vs brittle HTML markup
• Complete keyboard support
• Complete SUI component definition support
• Completely documented
• Completely tested
• Accessible

Credit

Created by @levithomason and an amazing community of contributors.

Made possible only by @jlukic authoring Semantic UI.

Blazing deployments by Vercel.

semantic-ui-react's Issues

Support all dropdown types

http://semantic-ui.com/modules/dropdown.html

Spread unhandled props on the root element

The issue I am running across, is when passing a style object into the Checkbox component, it acts as it should and applies styles to the actual checkbox input, yet I need the styles to be attributed to the parent 'ui checkbox' div in order to get it to float right as needed.

Here is a screen shot of how the custom styled checkbox renders:

Because the style shows on the input, and not the parent semantic div, the entire checkbox semantic element does not float right as it should.

Here is a screenshot of the rendered markup:

DATEPICKER

Doesn't currently exist in semantic at all. We need them to change graph scopes on FA

Warn when duplicating classes

A <Button /> adds classes ui button by default. Warn the user if they supply duplicate classes.

Right side width

The right side (content not left menu) doesn't have a responsive width. Below 1400px or so, the content goes out of the right side of the browser. It should respond to window size.

Static meta info object

If we add some kind of static _meta data object to the components it would make many things easier and our generated docs and tests more declarative. It would be an object containing type, name, and parent which would allow classifying the component declaratively. Example, a <Field /> would have a _meta as follows:

static _meta = {
  type: 'collection',
  name: 'field',
  parent: 'form'
};

This component is organized in Semantic UI as a "collection". It is not a top level component, but part of the "Form". The class name and filename should already be named Field by convention. This gives a declarative place it can be found. We can use this for generated documentation, testing, and for #69 spreadable props util.

Docs Use
The docs would use it to organize the menu, examples, generate links to Semantic's docs, and determine when to deep link to things like plugin settings (if the component is a "module").

Tests Use
Conformance test would use it to determine which standards this component should comply with. Example, if the component is a module, ensure the settings prop was not spread.

Util Use
propsUtil.getSpreadableProps() would use it to determine if the settings prop should be removed or not.

Use cases would continue to grow I'm sure.

EDIT
Speaking of which, we have some components that are not included in Semantic. Like the Confirm component. These are of type addon currently.

static _meta = {
  type: 'addon',
  name: 'confirm',
  parent: null
};

Using this, we can determine if a component is a Semantic component or a Stardust component. Even better, we may just add a isSemanticUIComponent key. This will be useful for things like #71 #72, conformance testing.

Add <Buttons />

http://semantic-ui.com/elements/button.html#buttons

Solidify Form validation and submission pattern

🪲 As a vendor, I want to know what registration fields are required, so that I don't skip important information

---

• Create a working example form with validation, submission, and data handling (serializing).

Semantic UI form validation is built in and works with the form state and messages. We may or may not want to use this, but it should be understood before making final decisions.

Select Input Needs to be Controlled Component

Currently, the Select element does not take in a name Proptype, and therefore when used in a Form component, renders the serialized JSON key for that specific input as null.

Also, the select element needs to have a handleChange() function to make it a controlled component.

<List /> component

And a <ListItem /> component

Example display order

On the doc page the examples are displaying in alphabetical order based on file name. Ideally, we could control the display order. That way we can display new elements in logical/sequential order.

README needs to say Babel stage 0

Add Webpack config to README

Just below Babel to show how to use loaders to compile Stardust in your project.

Nesting an <Input /> in a <Field />

When nesting a Stardust <Input /> in a <Field />, extra markup is generated.

Semantic field markup consists of a field div around an input:

<div class="ui form">
  <div class="field">
    <label>User Input</label>
    <input type="text">
  </div>
</div>

Semantic input markup consists of a ui input div around an input:

<div class="ui input">
  <input type="text" placeholder="Search...">
</div>

There is never more than one div wrapping an input. The div is either a field div or a ui input div.

Since Stardust <Field /> and <Input /> components both have an outer div with their respective Semantic classes (field and ui input) we get two divs wrapping the input when we nest them like so:

<div class="ui form">
  <div class="field">
    <label>User Input</label>
    <div class="ui input">
      <input type="text" placeholder="Search...">
    </div>
  </div>
</div>

With limited examples at tests at the moment, it is not clear if this is a real issue. Though, it is improper use of the framework and we should find a solve for it.

Conformance test for element and plugin

Semantic Modules each have a plugin. We expose this plugin at this.element.<pluginName> which is the component name. The element is the jquery element. We should test that both the element and the plugin are exposed.

Also, we should test that the plugin is called on componentDidMount, and that this.element.off() is called on componentWillUnmount.

To do this, we should certainly add the meta info in #70 so that we can determine if this is a Semantic component and if it is a module.

Before embarking on implementing this functionality in all components, consider a decorator that adds this boiler plate.

Add offset to Columns

<Column width={4} offset={2} />

Fubhub integration is needed.

Support Fields element

<Fields /> are for grouping <Field /> elements.
http://semantic-ui.com/collections/form.html#fields

The evenly divided variation is achieved by adding the number of child <Field /> elements as a class name. Suggest we expose a bool prop for this and automate the number by counting the number of child <Field /> elements.

All other variations should likely remain as className options.

Code coverage

We need some code coverage and a badge.

Support <Divider />

http://semantic-ui.com/elements/divider.html

Cleanup redundancy in tests

There is a lot of redundancy in tests. Mostly, findFoo() calls serve both query and assertion purposes. These are equivalent:

let gridClassName = render(<Grid />).findClass('sd-grid').props.className;
gridClassName.should.contain('sd-grid');

render(<Grid />).findClass('sd-grid');

Update all tests to remove their redundant assertions.

Replace class usage with attributes.

Button

- [ ] fluid - [ ] colors (all semantic colors) - [ ] size (all semantic sizes)

Image

- [ ] fluid - [ ] rounded - [ ] circular - [ ] ["top aligned", "middle aligned", "bottom alignded"] - [ ] size - [ ] centered - [ ] bordered - [ ]

Remove all styles from stardust

There should be no styles in stardust. and change out radium with default Semantic UI.

Generate changelog on deploy

We're using https://github.com/skywinder/github-changelog-generator. When deploying master, this should just be regenerated.

Button warning

I get this warning:

when running this code:

<Button className='icon ui fluid inverted button'>
  Earnings
  <i className='dropdown icon' />
</Button>

Remove bluebird dependency

Currently, the Modal is the only component depending on bluebird. It would be nice to not have an extra dependency for just one component. Explore other options.

Need component for radio input

We need a component for radio input. At the moment we only have checkbox. See the radio section in the Semantic docs:
http://semantic-ui.com/modules/checkbox.html

Input does not handle labels

Though the Stardust Input API may be different than what was attempted below, we should be handling this functionality.

Floated examples break the docs code layout

This can be easily circumvented if the code snippet were in its own column. There should also be some more padding between examples. We should toss that in this fix as well.

getSpreadableProps util

A util for getting spreadable props, to handle this use case:

let checkboxProps = _.clone(this.props);
delete checkboxProps.settings;  // all modules need to do this
delete checkboxProps.className; // this would be passed in

// then

<input {...checkboxProps} />

We need to remove props.settings from all Semantic UI Modules. Also, many components need to exclude certain props from being spread as they belong elsewhere. Like the checkbox example above, and this message example:

let messageProps = _.clone(this.props);
delete messageProps.icon;

// then

<div {...messageProps}>

The icon prop belongs as classes on the icon inside the message, then the rest of the props are spread.

This should be abstracted away with a util that understands what to do to get spreadable props.

Create attached button element

We want to be able to use a Button element attached a div. Currently, when set as a Button it doesn't adopt the styling of the attached div. See PR #45

ttest

Add toggle button functionality

Let's add the functionality for the toggle button. Here's the toggle button on the semantic docs - http://semantic-ui.com/elements/button.html#toggle

Add animation to Modal Show AND Modal Hide

modal component should fade in / fade out when being shown.

Need Generic Select Component

This is separate from creating a semantic ui specific [Dropdown]ttp://semantic-ui.com/modules/dropdown.html).

What is needed is a simple Select component that is a select input type to be used in forms. Please note it will also specifically need a multiple prop that will allow you to choose multiple inputs if needed. Code example below:

import React, {Component, PropTypes} from 'react';

class Select extends Component {
  static propTypes = {
    label: PropTypes.string,
    multiple: PropTypes.bool,
    options: PropTypes.array,
    value: PropTypes.oneOfType([
      React.PropTypes.string,
      React.PropTypes.array,
    ]),
  };

  render() {
    let options = this.props.options.map((opt, i) => {
      return <option key={i} value={opt.value}>{opt.text}</option>;
    });
    let value = _.isEmpty(this.props.value) ? '' : this.props.value;
    return (
      <div>
        <select {...this.props} className='sd-select ui fluid dropdown' value={value} multiple={this.props.multiple}>
          {options}
        </select>
      </div>
    );
  }
}

export default Select;

ListItem updates and fixes

Icon Prop

• define propTypes for string and instanceOf i (will be </Icon /> when merged)
• if a string, construct an <Icon /> with the string as classes
• otherwise, render as is

Image Prop

• define propTypes for string and instanceOf <Image />
• if a string, construct a <Image className='avatar' /> with the string as the src
• otherwise, render as is

Description and children

• Allow a description prop to defined and children. Currently, children override the description in render which breaks nested lists.

Cleanup

• use getUnhandledProps util instead of cloning and deleting prop keys (example in Checkbox).
• do not _.clone() props for no reason, just use the prop directly.
• do not const foo = this.props.foo for no reason, just use the prop directly.

Examples

• update examples to use new icon/image prop capabilities

  For brevity, I think we should use faker and the image string option for all examples: <ListItem image={faker.internet.avatar()} />. Then, just show one near the top that shows you can also pass in an image element. This way, there aren't so many examples that import and construct images to show the list.

• update nested list example, removing the extra div (fixed by children/description task above)

Use local modules in dev

User bower components during dev for faster reloads. import $ from 'jquery' should be a webpack'd to the bower component.

Use cdn's in production.

CustomPropTypes util

As mentioned in #65 we should start a custom prop type util:

• mutually exclusive prop type:

  // warn if "description" and any of these others are defined
  description: customPropTypes.mutuallyExclusive(['children'])

Create Container Element to Handle Container classes

Create Container Element to Handle Container classes

Do Inline Fields Work?

I wanted to do something like this:

With syntax like this:

<Field
  width={8}
  label='Name'
  className='inline'
>
<Input
  placeholder='First Name'
  onChange={this.handleChange}
  value={this.state.user.firstName}
/>

but I got this:

Is my syntax off or is this a real issue?

Set value instead of object for serializing Form data

current method of serializing.

        switch (node.getAttribute('type')) {
          case 'checkbox':
            json[name] = {checked: node.checked};
            break;

          case 'radio':
            json[name] = {
              value: _.find(arr, {name: name, checked: true}).value
            };
            break;

          default:
            json[name] = {value: node.value};
            break;
        }

A <Divider /> element.

Conformance test for children/description/text props

Some components will take a description or text prop. These props may also be defined using children.

In the case where children and another conflicting prop is defined, the children prop should win. We should be able to test if the current component is a Semantic component (see #70), and if it has a description/test prop, then test that the children prop wins if both are defined.

Restructure sub components

Currently there is one flat level of components in stardust, Modal, ModalFooter, etc. This is leading to confusion for some components (List, ListItem, Item). Refactor to use the format suggested by the React docs.

import {List, Table, Menu} from 'stardust';

const list = (
  <List>
    <List.Item />
  </List>
);

const table = (
  <Table>
    <Table.Column />
  </Table>
);

const menu = (
  <Menu>
    <Menu.Item />
  </Menu>
);

This will also remove the need for the parent key in the _meta description as the relationship will be declarative. Generating the nested doc menu will be a breeze as well.

Drop /dist build

This is currently broken and not required. The src is better since webpack can optimize it when the user imports it.

Tests for customPropType utility

Need to make sure and test the functionality of the mutuallyExclusive function within customPropType.js utility to expect it to throw an error if two props that are mutually exclusive exist together.

Duplicate random data causing intermittent Table test fail

The table column test ensures there are no columns present for the TableColumn that was removed from the table definition. However, sometimes, there are two columns with the same name generated. Removing one, and testing that all are not present fails.

Instead, get a unique list of table columns before continuing.

In table test:

  describe('row', () => {
    it('only contains cells that were defined in TableColumns', () => {
      render(
        <Table data={tableData}>
          <TableColumn dataKey={randomDataKey} />
        </Table>
      )
...

Component guideline test

There should be a test that ensures a component adheres to the guidelines. We should then loop through all the components on stardust and run the test against them.

---

Tests

• className is inherited.
• If the underlying class name follows ui <component> format, className is inherited between ui and <component.
• If the underlying class name does not include ui, className is inherited before the component class. Example, fields only have a field class, inheritance is <className> field.
• props are spread on the underlying element.

Use default props and params

Search for || and replace default props and default function params where possible.

new issue