cloudflare / cf-ui Goto Github PK

:gem: Cloudflare UI Framework

License: Other

JavaScript 99.30% Shell 0.64% HTML 0.07%

cf-ui's Introduction

cf-ui (not maintained)

This repository is no longer maintained. We decided to merge cf-ui into our internal monorepo and we will keep the future development there. We do not accept pull requests here. However, we plan to synchronize our internal changes with this repository.

Cloudflare UI Framework

cf-ui is a set of over 50 packages used to build UIs at Cloudflare using projects such as React, Fela, Lerna and more.

Usage

Whilst cf-ui is used extensively within Cloudflare, it is also an evolving set of components and therefore can be unstable. We recommend only using this toolset to build interfaces for Cloudflare-internal products. However, feel free to follow along and contribute as we continue to grow this library.

cf-ui meets CSS in JS

We are currently migrating cf-ui to CSS in JS powered by Fela. That means that our components include styles written in JavaScript and you can use them out of the box! However, you need to start using Fela in your project. Follow our migration here.

Getting Started

To view all of the available components and packages, see the packages/ directory. Do you want to see examples? Check out our documentation.

CSS in JS setup

cf-ui components expect that there is Fela Renderer in the context of your React app. It's the way how to render styles that come with our components into the <style></style> node. You have to use Fela in your project if you want to use cf-ui. Here's the code example how:

import React from 'react';
import ReactDOM from 'react-dom';
import { StyleProvider } from 'cf-style-provider';
import { Button } from 'cf-component-button';

ReactDOM.render(
  <StyleProvider>
    <Button type="primary" onClick={() => console.log('clicked')}>
      Primary Button
    </Button>
  </StyleProvider>,
  document.getElementById('react-app')
);

Do you want to try for yourself?

git clone [email protected]:cloudflare/cf-ui.git
cd cf-ui/packages/example
npm install
npm run build
open index.html

Contributing

To get started contributing please see CONTRIBUTING.md

License

cf-ui is BSD Licensed

cf-ui's People

Contributors

Stargazers

Watchers

cf-ui's Issues

Reducer state location

I noticed in the card builder this project assumes state.cards is where the reducer is mounted. Is this a safe assumption?

I'm having a similar problem in my own codebase and I wonder if there are better strategies then expecting state to be in a specific spot.

I feel like this breaks encapsulation because it forces you to mount the component at the top of the state tree in a well known location.

Any ideas?

Schedule to push React 15 to npm

Is there a schedule or roadmap to push React 15 changes to npm? This will help to pull changes directly from npm instead of referencing them locally.

Change activeTab to active in cf tabs component

Creating this issue to track the PR for moving to active from activeTab prop in the cf-component-tabs package.

So far I've only found the following use of activeTab in www-next.

containers/analytics/billboard/RateLimitingCard.js:

Upgrade eslint to 3+

Set up CI

@jwineman said he wanted to get CI up and running. Travis should help with linting, but if we could set up saucelabs to run tests in many different browsers, that'll be really nice.

Missing prop types descriptions in docs

The prop type descriptions are missing from the README files of individual packages and also on the external example websites. Actual src in packages is fine, just the docs are missing the prop descriptions.

The descriptions should be below the example, but theyre not. See screenshot.

cf-util-http doesn't convert application/json responses to JSON

In https://github.com/cloudflare/cf-ui/blob/master/packages/cf-util-http/src/http.js#L64:

body: headers['content-type'] === 'application/json'
      ? JSON.parse(text)
      : text,

For responses with a Content-Type: application/json; charset=UTF-8, this will fail. We should check that the Content-Type header contains 'application/json'.

Tooltip position

First of, you guys did an amazing job on the CF-UI.
Browsing the components i noticed that tooltips can
popup on the edge. Maybe position calculation can
be based on if the tooltip content might be obscured,
rather than only when the element (button) is obscured.

http://recordit.co/VLnuvxiyP7

Allow all UI components to accept extra class names and modifiers

A lot of the components have hard coded class names and states that get appended to the class names, but we can't append to the class names when customizing, either to override the styles in a specific component in a certain context, or introduce contextual BEM modifiers that will only be apparent at the use site.

Improve cf-util-http API

https://github.com/cloudflare/cf-ui/blob/master/packages/cf-util-http/src/http.js#L107

The node convention is to put the callback as the last param, but this creates a UX problem for optional params in the middle of the method. By definition if any param is optional, it should be not be required, but we are still requiring the user to put an undefined there. This is stupid.

Remove cf-component-select

It's basically a wrapper around react-select at this point but with a wrong API and bugs (see #165)

Latest release of fela broke our tests

What happened:

Fela released a new version (2 hours ago) which broke 11 tests.
Tests pass on version 4.2.6.

Solution:
lock dependencies with yarn. Upgrade dependencies through PR.

Remove experimental draft ES constructs

We are using a lot of experimental stuff like class properties, a withdrawn syntax for export default and object spread. Since only object spread seems to be going somewhere, I propose we remove class-properties and export-extensions. This will also stop ESLint from complaining without having to do weird things to it.

Functional components

Related to #161

Let's ID a list of components we have a high degree of confidence we'll never need the ref, then convert them to functional components, or if we can, PureComponents, so they can be faster now without having to wait for Fiber.

cf-util-http API incompatible change

with latest release 3.5.0 of cf-util-http we introduced breaking change in the API. Now we use default params for opts https://github.com/cloudflare/cf-ui/blob/master/packages/cf-util-http/src/http.js#L107. This is a problematic, because it will set default value if only undefined is passed. The previous versions worked with null just fine, but now passing null value breaks on the first line https://github.com/cloudflare/cf-ui/blob/master/packages/cf-util-http/src/http.js#L108, because opts is null.

Proposal: release fix for 3.5.1 which allow null in the meantime. Default params change is semver major. We should allow gradual upgrade path.

Missing react-fela in `cf-component-button` 4.0.0

This code:

import React from 'react';
import {render} from 'react-dom';
import {Button} from 'cf-component-button';

const App = () => {
  return <Button>Click me</Button>
}

render(<App />, document.querySelector('body'));

results in this error
stderr: Error: Cannot find module 'react-fela' from '/tmp/cf-component-button117127-29294-18e4ou5/node_modules/cf-component-button/node_modules/cf-style-container/lib'

Migrate to Webpack

So we can remove the bulk of hand written gulp stuff, get a faster build process and application code can take advantage of Webpack's treeshaking.

https://webpack.js.org/guides/author-libraries/

Style issue with cf-component-heading

After running styles in cf-styleguides, I noticed that a heading with size={1} had a slight font-weight issue.
This is what it looks like now

And this is what it should look like

Fela is injecting font-weight:400 into the size={1} heading.

Not a big issue but I thought I'd report it.

Remove all traces of findDOMNode

findDOMNode is going to be deprecated, so we have to remove them.

jsx-eslint/eslint-plugin-react#678 (comment)

Format classnames with classnames

@jculvey suggested using https://github.com/JedWatson/classnames to format component classnames.

I'd be happy to add it and update any modules that might need this utility

Deprecate cf-component-viewport

We haven't found much use of it and it's not particularly performant. Media queries are best dealt with via either a style sheet or some css-in-js solution.

Add jsnext:main to clarify that the code is ES2015

See reasoning here: https://github.com/rollup/rollup/wiki/jsnext:main

Jest for testing

The current tests are... slow. Also, snapshot tests would be great for our use-case (we could cut the size of tests in half).

So, how do you feel about leaving Karma/assertEqualJSX and using Jest + node.js? Running tests in real browsers is nice but the speed is everything.

Remove hardcoded cross dependencies

We should change APIs of some of our components. For example, ModalTitle.js looks like this:

import React, { PropTypes } from 'react';
import { Heading as HeadingUnstyled, HeadingTheme } from 'cf-component-heading';
import { applyTheme } from 'cf-style-container';

const Heading = applyTheme(HeadingUnstyled, HeadingTheme);

class ModalTitle extends React.Component {
  render() {
    return (
      <div className="cf-modal__title">
        <Heading size={3}>
          {this.props.children}
        </Heading>
      </div>
    );
  }
}

ModalTitle.propTypes = {
  children: PropTypes.node
};

export default ModalTitle;

The problem is that the styles are hardcoded here and not changeable by consumer. We should change API of ModalTitle.js to

import { Heading as HeadingUnstyled, HeadingTheme } from 'cf-component-heading';
import { applyTheme } from 'cf-style-container';
const Heading = applyTheme(HeadingUnstyled, HeadingTheme);

<ModalTitle heading={Heading}>

So you can style it outside. Of course, in our case it would be like this:

import { Heading } from '@cloudflare/cf-component-heading';
import { ModalTitle } from '@cloudflare/cf-component-modal';

<ModalTitle heading={Heading}>

Remove packages

So after much internal discussion and listening to my inner voice, I want to formally declare I want to remove these packages, and solicit comments on these proposals:

cf-component-heading
There's no standalone <h1-6>, every time they are used in a component, even if it's the same
<h1>, they may still look slightly different. There's no one size fits all component we can
generalize here. Just use react-dom, and style it your way depending on context.
cf-component-flex
Utterly useless. Whitelisted props, no vertical rhythem checks in them, not even box model
properties are allowed. We've already replaced it with <Box>. Everybody hates <Flex> and
nobody wants to maintain it. Let it die.
cf-component-layout
This is essentially a grid system. Larger composite component were already designed with a grid
system, and the styles have the grid melted into them. We already have <Box> that allows us to
use flexbox. If we really need a standalone, lower level primitive that's grid system, let's
reintroduce a real one done with CSS grid layout.
cf-component-text
Remnant concept from bootstrap, except instead of being helper classes that can be applied to
anything, we are only allowed to use it to render <div>s, not even <span>. Let's just use
polished to make some equivalent helper functions that decorates fela style objects.
cf-component-typography
I have no idea why we have a bunch of super low level inverted HTML typographical components.
Are these just placeholders for CSS resets? They've never been used, probably because nobody
wants to import them, and these elements just aren't that commonly used because Markdown.
Let's just move these super baseline styles into a global static stylesheet.
cf-component-viewport
See #68
cf-util-async
It's nice that you can do parallel and series with node CPS callbacks, it's sad that nobody has
found any use of them. Deeply nested callbacks are annoying and hard to follow. Nobody likes
hourglass shaped code. cf-util-http already takes care of 90% of our use cases where we need
to do async stuff.
cf-util-cache
Redux store is our cache now. Having to manage the cache is historically one of the biggest pain
point in www-next, also one of the hardest problem in computer science. Just refetch everything
when they are needed, so the data won't get as stale. Render the UI optimistically, with
strategically placed loading visual feedbacks. Facebook is a good pattern to follow here.
cf-util-logger
Just because we are currently using deadorbit, which uses debug, it doesn't mean we should
continue to use it. What's wrong with console.*? It's only used in 2 places in cf-ui now, 1 is cf-
util-cache, another is cf-util-http. Easy.

Please feel free to comment on any of them. My only major gripes are heading/text/flex/layout/typography. No other set opinions here.

cf-test-server has almost the same README.md as cf-test-store

Compare cf-test-server's README.md with cf-test-store's README.md. Seems this is just another copy-paste issue.

cf-component-tooltip doesn't reflect changes in `content` prop

It looks like cf-component-tooltip reads the content prop once at initialization and never again, meaning that when content changes, the changes aren't reflected in the tooltip.

cf-component-tooltip should implement componentDidUpdate and compare props, then recreate the tooltip if changed.

npm test fails without running npm run build

before PR was landed, this worked:

npm install
npm run bootstrap
npm test

now we have to run 3 steps before running test:

npm install
npm run bootstrap
npm run build
npm test

I assume it was an intended behavior, on the other hand, we should reflect it in the README and CONTRIBUTING docs. I also think we could move aliasing step outside of the build step and run it within npm run bootstrap.

Another note, after running npm run clean we need again 2 extra steps before able to run tests:

npm run bootstrap
npm run build
npm test

Deciding the fate of Link component

Current Situation
I was migrating cf-component-link to Fela and noticed that we have a dual implementation in the component. So I have some questions about how we want this component to behave.

Currently, the component accepts a tagName that is rendered instead of <a></a>. The component also accepts a to prop that is used to route to a location.

I've noticed use cases of cf-component-link where "link should look like a link but act like a button".

The tagName and to props introduce quite a few if statements into the component. These statements check for href, onClick, to and call different functions accordingly. This also diverges from the idea of having a standardized component library by allowing a user to render anything as a link using the tagName prop.

Questions

Should we remove the ability to make anything a link? i.e. Always render an <a>{children}</a>
Should we remove the {to} entirely and have just an onClick handler. This will satisfy the button use case. The routing can also then be handled using the onClick handler.
OR
Should we keep the {to} and remove the ability to call a custom onClick handler. This will force users to restyle the cf-component-button to look like a link (which would now be super easy using Fela). Routing can then be handled using the to prop.

Upgrade Karma to 1.3+

cf-component-tooltip can't be server-side rendered

It uses "tether-tooltip" and that library touches DOM all over the place. The new styleguide is going to be server-side rendered so this is breaking my styleguide build currently. I'm going to remove it from the styleguide and we should replace "tether-tooltip" with something better.

react-tooltip looks pretty good and we could preserve similar (same?) API.

I tried many hacks and tricks how to bypass it on server but it's not worth of effort just because of one single component.

In general, all our cf-ui component should be compatible with server side rendering.

cf-component-card drawers don't expand

https://cloudflare.github.io/cf-ui/#cf-component-card

Pressing One and Two does not make the card expand.

Change baseline to 24px

Our current baseline is 15px (font-size) * 1.5 (line-height) = 22.5px. This is a sad baseline. We should make it something that works out better mathematically, like 24px.

The work would entail changing the entries in cf-style-const. In addition, add back the line height checks in cf-component-box once the new baseline is established.

Remove cf-util-text and deprecate the package on npm

This was only introduced for copyable-textarea at the 11th hour, this dependency has been removed.

UI library code should only provide a way to customize text as opposed to mandating yet another half done gettext style library.

Need default values for IE in cf-component-flex

Because of this:

https://github.com/philipwalton/flexbugs

Fix flaky test for cf-component-notifications

All pure components should accept all DOM props

cf-ui has a ton of pure components that only do 2 things:

Apply BEM classes
Prevents outside code from directly setting any event handlers and props on the contained React DOM element that's not whitelisted by the pure components themselves.

is preventing us from setting event handlers on form elements and sometimes completely valid HTML 5 properties. All pure components should allow all of the attributes and event handlers accepted by the wrapped elements themselves when possible. Special handling for some attributes and event handlers might be needed, but they should be dealt with on a component-by-component basis and should not hinder this issue.

cf-component-box fontSize PropType

cf-component-box specifies a number PropType. How do I go about passing it a '0.9rem' size?

cf-style-const specifies a px string, which is incorrect, no?

Add TypeScript definition files

TypeScript definition files would allow users of TypeScript, Flow, or any other typed variation of JavaScript have types.

Publish with --only-explicit-updates

Lerna allows publishing only explicitly updated packages instead of it and all the packages that depend on it, and all the packages that depend on the the dependencies at infinitum.

This is nice since there are so many packages in cf-ui and the inter-dependency graph is very intricate. It's doesn't seem to make sense to have a new version of cf-component-button, if every code change happened in say cf-style-const.

A concern was raised by @tajo that if a UI component changes its layout that affect their users, e.g. cf-component-table renders divs instead of table components, such that cf-builder-table renders completely differently now. cf-builder-table should be automatically get a version bump during publishing too, even when no code has changed in the builder. I would argue this is still an invalid argument because this should never happen. If cf-component-table changes the layout, and breaks cf-builder-table, cf-component-table should get a major version bump so no consumers will be broken.

Thoughts?

Inconsistancy between cf-component-input example website and master

I noticed that the cf-component-input on the example website is out of date. Specifically the handleChange and constructor functions.
The master build however, shows the correct example. Not sure if this is something to do with a publishing issue.

https://cloudflare.github.io/cf-ui/#cf-component-input

https://github.com/cloudflare/cf-ui/blob/master/packages/cf-component-input/example/basic/component.js

Fela Migration

Lets track the migration of these components here. Call out what you're working on and I'll keep this thread up to date.

8 / 33 ( 24% ) complete.

Snapshoting generated styles (full render instead of shallow render)

We always do shallow render to test our components. So you can see changes in the DOM markup and you can see the classNames changes (styles changes). However, you can't see specific CSS rules changes. We would have to do full rendering with JSDom instead, so you have access to <style>. I already did it for one test.

The resulting snapshot:

exports[`StyleProvider should render styles 1`] = `
"<!DOCTYPE html>
<html>

<head>
  <style id=\\"stylesheet\\" data-fela-stylesheet=\\"\\">
    .cf-a {
      margin: 10px
    }

    .cf-b {
      color: red
    }
  </style>
</head>

<body>
  <div id=\\"react-app\\">
    <div data-reactroot=\\"\\" class=\\"cf-a cf-b\\"></div>
  </div>

</body>

</html>"
`;

So this gives nice diffs even for CSS. This is more a thing for rainy day if we want to step up our testing game even more, so I'll leave it here. It would involve to abstract some of that JSDom setup and updating all current snapshot tests.

cf-component-select defaults to searchable

cf-style-provider

We should abstract Fela support into its own package since we now do very similar setup in cf-ux (for testing), cf-ui (for testing), cf-styleguide, cf-www-next, NP and partners. It would automatically also add our global theme (cf-style-const) into the context.

New simplified setup

import { Provider } from 'cf-style-provider';
import { Button, ButtonTheme } from '@clouflare/cf-component-button';

const fontNode = document.getElementById('font-stylesheet');
const cssNode = document.getElementById('stylesheet');

render(
  <Provider fontNode={fontNode} cssNode={cssNode}>
      <Button type="primary" onClick={() => console.log('clicked')}>
        Primary Button
      </Button>
  </Provider>
);

compare it with the example in README. I think that 3rd party consumers of cf-ui still might want to rather do more manual setup since they don't want to be locked in into our global constants and set of Fela plugins but useful for us.

cf-component-button has a required onClick prop

I wanted to make a submit button but I keep getting errors because it wants a onClick.

Upgrade superagent

We are using superagent 1.x in cf-util-http, superagent is at 3.x now. Should probably upgrade before it's too late.

cf-component-button doesn't have a form property

I need a form property to submit a form that the button isn't encapsulated by. See this

cf-builder packages

We don't use them at all, so let's discuss why. They should make our life easier when using cf-components. That means we need to find some common patterns that they could solve:

do we use similar structure for 80% of tables? If yes, let's update cf-builder-table and use it instead of "cooking" UI out of cf-component-table every single time
the same for cf-builder-card
cf-builder-pagination seems pretty general and useful as it is

We should also remove redux / local states and pass everything through props. Devs usually want to have complete control over the state. Also, we are autogenerating a lot of Redux stuff, so this can't really work for us, right?

TravisCI runs on push and pr

If we modify it to just run on push this will cover both edge cases right?