CSS in JS Transition: First Step

[tajo]

What's new

• update (pretty much rewrote) cf-component-button
• add a new component cf-style-container, it is a wrapper for some fela APIs so we can keep the rest of components fela free
• add a new build process for the style guide
  • it lives in the /styleguide dir
  • it's a full-fledged app using webpack2
  • it directly imports components from /packages/cf-xxx-xxx/src/xxx.js
  • you can do local deving with hot module replacement via:

  npm start
  open http://localhost:8000
  

  • you can get static version (that will be published) via:

  npm run examples:new
  open build/index.html
  

  • it's using a webpack loader to create and highlight code examples
  • it's using webpack aliases so we don't have to use relative paths in the code examples

What's broken

• We need to approach tests differently since classNames are dead (auto-generated). I want to setup Jest and snapshot testing. Right now, I commented out the test for cf-component-button.
• We have to ignore new components in old gulp tasks since it wouldn't work (missing styles and broken paths since it's using browserify). So you can still build old style guide but without transitioned components.

What's next

• This PR is pretty rough but cf-component-button won't change much. I will have to do some updates so it supports our internal styles.
• The new style guide is a POC right now:
  • First, I want to match the look and functionality of the current one. I'll have to create another webpack loader to extract propTypes. (we are moving gulp code into webpack loaders, how cool is that?)
  • I will create a CLI tool that will autogenerate the whole /styleguide folder. So we can easily use it for private cf-ui as well. The same approach as with doca.
  • I might add some new features for designers (think of live editing of themes).
• I'll create @cloudflare/cf-component-button

[tajo]

Please ignore linting. I'll switch cf-ui to prettier soon, so I didn't care.

[hturan]

This is ace, thanks for putting it up for review! I haven't had a chance to go over the fela re-write yet, but have some notes concerning the styleguide.

It's worth noting that there's currently an internal project to create a styleguide, so I'd hold off creating anything too revolutionary for now. I'm all for refactoring into a styleguide app (in fact, that's exactly what I did when I created my dynamic styleguide proof-of-concept; making a webpack app in /styleguide directory), but maybe just duplicate the functionality and design we have now (but using webpack instead of gulp) 👍

Also FWIW, as part of the dynamic styleguide I made (the one that gave you editable PropTypes via HTML inputs) I created a PropTypes webpack loader that used react-docgen to process the raw component source. It was pretty hacky and failed on a few components due to weird dependencies, but I'm happy to send you the source if you're interested. For now, it might be worth just taking the source parsing logic we have in the gulpfile and moving it into a loader. Let me know if you need a hand with this!

[wyuenho]

This is awesome. I see some short hands used but I guess they are allowed since it looks like fela just uses the DOM's style properties. It's been a while since I've used them, it's a bit surprise to rediscover that some CSS properties don't support shorthands, but some do. Is this still a concern?

Just a few question, since we've moved all docs to go under /docs so Github Pages can serve them, this styleguide is intended to replace that at some point right? Also, now that webpack is in place, this means we can conceivably remove a hugh chunk of code from the gulp file that has to do with the examples, and pave the way to use webpack to compile all the components in the future right? Can you write down your plans on the Webpack ticket?

[wyuenho]

Why do you need this?

[tajo]

Good catch. I'll remove it.

[tajo]

Done.

[jwineman]

Why the trailing underscore on packages/cf-component-button/test/Button.js_?

[jwineman]

outdated nvm

[tajo]

@hturan It seems we are working on the same thing. Can you send me a link? To make it dynamic (with HMR) it needs to be a part of cf-ui repo. Only this way, you can have the best dev experience (no rebuilding, no refreshing). I think we should merge everything into the styleguide app. I'll bring it up to the current functionality. We can start adding new features later (live editing through HTML inputs would be really cool).

For now, it might be worth just taking the source parsing logic we have in the gulpfile and moving it into a loader.

That's exactly my plan.

@wyuenho You can use shorthand properties or longhand properties, but you can't combine them in the same rule. I think we should mostly avoid shorthand properties (especially for common properties as margin, border or padding). It adds some extra code but it will cut the size of CSS output in a long term since longhand properties are more unique and can't benefit from Atomic design that much. Also, it makes customization easier (if I used shorthand margin for the button component, its rule function would be a mess). I don't have a strong opinion on this yet. Let's see what our experience will be but not using shorthands definitely will not hurt.

Ad webpack. Yes! Once we transition all components, we can remove gulp completely. Examples are handled by /styleguide (notice that big chunks of gulpfile code are replaced by webpack loaders) and build can be done with a npm script/webpack too.

[wyuenho]

let's call this node or element, type is overused

[tajo]

That's what fela is using now so I want to match their API/terminology if possible. Node / Element has meaning in DOM terminology. This actually accepts React components as well.