semantic-org / semantic-ui-react Goto Github PK
View Code? Open in Web Editor NEWThe official Semantic-UI-React integration
Home Page: https://react.semantic-ui.com
License: MIT License
The official Semantic-UI-React integration
Home Page: https://react.semantic-ui.com
License: MIT License
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.
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.
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.
Doesn't currently exist in semantic at all. We need them to change graph scopes on FA
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.
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.
We're using https://github.com/skywinder/github-changelog-generator. When deploying master, this should just be regenerated.
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;
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
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.
<Column width={4} offset={2} />
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.
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
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.
A <Button />
adds classes ui button
by default. Warn the user if they supply duplicate classes.
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.
We need some code coverage and a badge.
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.
There should be no styles in stardust. and change out radium with default Semantic UI.
Just below Babel
to show how to use loaders to compile Stardust in your project.
Create Container Element to Handle Container classes
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.
Search for ||
and replace default props and default function params where possible.
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
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;
}
<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.
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>
)
...
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.
And a <ListItem />
component
This is currently broken and not required. The src is better since webpack can optimize it when the user imports it.
Icon Prop
i
(will be </Icon />
when merged)<Icon />
with the string as classesImage Prop
<Image />
<Image className='avatar' />
with the string as the src
Description and children
description
prop to defined and children. Currently, children override the description in render which breaks nested lists.Cleanup
getUnhandledProps
util instead of cloning and deleting prop keys (example in Checkbox
)._.clone()
props for no reason, just use the prop directly.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)
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.
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.
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.ui <component>
format, className is inherited between ui
and <component
.ui
, className is inherited before the component class. Example, fields only have a field
class, inheritance is <className> field
.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'])
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.
modal component should fade in / fade out when being shown.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.