Segment Examples

[ghost]

Adds Semantic UI Segment examples to the Stardust repo. Also creates a Segments component which works in concert with Segment to provide grouping behavior. Segments component is considered a child of Segment from a documentation purpose and so it does not appear in the list of components, but will appear in the examples.

Resolves #112 and closes #114. Discovers #116 and #120.

[ghost]

@levithomason this would be our first use of fbjs to throw a possible invariant violation in this repo. The intent is to help prevent misuse of the components. Still need to add support for nested groups. (Note: the second argument to invariant is optional and would shed some weight during production builds if omitted.)

What's weird though is when I tried to create a simple invariant for Children(count) >= 2 - I ran into issues with conformance tests.

If we like the pattern we could also consider adding a runtime check for number of children, though that's something we may want to pair on given my failed attempts.

Alternatively we could try an approach more like this perhaps?

static propTypes = {
  children: PropTypes.oneOfType([
    PropTypes.oneOfType([
      PropTypes.instanceOf(Segment),
      PropTypes.instanceOf(this),
    ]),
    PropTypes.arrayOf(PropTypes.oneOfType([
      PropTypes.instanceOf(Segment),
      PropTypes.instanceOf(this),
    ])),
  ]).isRequired,
  className: PropTypes.string,
};

[ghost]

In attempting to allow Segments to support nested Segments I tried the propTypes approach, as well as the following without luck:

invariant(
  !_.any(Children.map(children, child => {
    return _.includes( ['Segment', 'Segments'], _.get(child, 'type._meta.name') );
  })),
  'May only contain children of type Segment or Segments.',
);

As a result, I'm going to backpedal to children: PropTypes.node for now, and remove the fbjs and invariant calls. The net result is the component will accept any children until we're able to figure out a method which works.

[ghost]

Per Reusable Components doc we should not throw, but return errors from custom validators.

[levithomason]

Nice catch, thanks!

[levithomason]

Nice, thanks for the anchor link here!

[kyleturco]

Another tiny difference between file & class name, just a bonus 's' 😉

[ghost]

All review feedback incorporated. While I was in there I also refactored Statistic to use the new custom propType created with this PR. In the refactored code we now have three import statements dipping into src/utils. If this gets unwieldy as more utils are introduced in the future we may want to look at allowing destructuring on src/utils.