cloudflare / cf-ui Goto Github PK
View Code? Open in Web Editor NEW:gem: Cloudflare UI Framework
License: Other
:gem: Cloudflare UI Framework
License: Other
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.
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'
I wanted to make a submit button but I keep getting errors because it wants a onClick
.
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.
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.
cf-ui has a ton of pure components that only do 2 things:
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?
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?
We are using superagent 1.x in cf-util-http, superagent is at 3.x now. Should probably upgrade before it's too late.
https://cloudflare.github.io/cf-ui/#cf-component-card
Pressing One and Two does not make the card expand.
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.
I need a form
property to submit a form that the button isn't encapsulated by. See this
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:
<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<Box>
. Everybody hates <Flex>
and<Box>
that allows us to<div>s
, not even <span>
. Let's just usedeadorbit
, which uses debug
, it doesn't mean we shouldconsole.*
? It's only used in 2 places in cf-ui now, 1 is cf-Please feel free to comment on any of them. My only major gripes are heading/text/flex/layout/typography. No other set opinions here.
It's basically a wrapper around react-select at this point but with a wrong API and bugs (see #165)
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?
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:
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?
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.
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.
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.
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.
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.
@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.
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.
Lets track the migration of these components here. Call out what you're working on and I'll keep this thread up to date.
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.
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
<a>{children}</a>
{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.{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.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.
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.
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.
@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
findDOMNode
is going to be deprecated, so we have to remove them.
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.
TypeScript definition files would allow users of TypeScript, Flow, or any other typed variation of JavaScript have types.
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.
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.
Compare cf-test-server's README.md with cf-test-store's README.md. Seems this is just another copy-paste issue.
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
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'
.
Because of this:
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.
See reasoning here: https://github.com/rollup/rollup/wiki/jsnext:main
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}>
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.
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.