Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Theme-ability progress #3572

Merged
merged 55 commits into from
May 19, 2018
Merged

Theme-ability progress #3572

merged 55 commits into from
May 19, 2018

Conversation

ndelangen
Copy link
Member

@ndelangen ndelangen commented May 11, 2018

Issue: -we want storybook to be theme-able / customisable-

What I did

I changed more components to use emotion for styling, I also modified some components to prepare for customisation/theming ability.

It also includes a new mobile layout.

So I migrated everything over to use emotion.. surprise. It's basically because of this:
paypal/glamorous#419

Also I was running into a strange snapshot mismatch issue. Hopefully emotion doesn't have this issue. 🤞

How to test

Run the examples, see chromatic diffs

@ndelangen ndelangen added ui maintenance User-facing maintenance tasks components labels May 11, 2018
@ndelangen ndelangen self-assigned this May 11, 2018
@ndelangen ndelangen changed the title [WIP] Theme-ability progress Theme-ability progress May 16, 2018
@tmeasday
Copy link
Member

Pity there isn't a good way to look at all the changed stories at once @ndelangen 🤔

Code-wise, looks great. Did the font color change slightly?

@ndelangen
Copy link
Member Author

The TeamCity official example is a pretty good indicator.

Indeed the main colour changed a bit, I'll work on a follow-up PR that consolidates the UI, and implements theming in more places.

Copy link
Member

@shilman shilman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Minor comments inline 👍

const Container = styled('div')({
width: '100%',
position: 'relative',
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...baseFonts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I want to cascade the fonts and colours down as much as possible to make themeing easier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an extremely good idea @ndelangen


import PropTypes from 'prop-types';
import React from 'react';
import { polyfill } from 'react-lifecycles-compat';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this have to do with theming? Can we move to another PR?

@@ -170,11 +170,6 @@ export class Panel extends Component {
this.iframe.style.height = viewport.styles.width;
this.iframe.style.width = viewport.styles.height;
}

// Always make parent's height equals iframe
if (this.iframe.parentElement) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this???

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I changed the way the overflow works for the preview

@@ -11,4 +11,4 @@

Storybook Components is a React UI components collection used by the UI of Storybook and Addons.

All components use [`glamorous`](https://glamorous.rocks) for styling.
All components use [`glamorous`](https://styled.rocks) for styling.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@Keraito Keraito left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refactor wise looks great as far as I could tell! Just some small remarks or questions.

marginBottom: '4px',
},
};
const Item = styled('li')({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is entirely based on code only: Is there a specific reason why the li element is styled instead of the ol? The previous implementation had the styles.element injected into both of them which looked redundant, so removing one of them is great. But functionality wise it doesn't seem like there's a difference between putting it on the li and ol. Readability wise this looks better, but is there any possible downside (performance/verbose output for DOM of the user) for not doing so or any explicit reason to do so? Mostly questions out of curiosity!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the li actually has user-agent styling applied to it, the ol doesn't as much.

};

class Layout extends Component {
constructor(props) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A decent amount of other components in this PR have their constructor and method bindings replaced by class properties and fields, while a lot have not. Would it be wise to choose 1 and stick with it throughout the project?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to write components using modules and module scope function and less with component instance function. That's just my coding style. (composition over inheritance)

Though I do believe that in a perfect world a codebase would be perfectly uniform, in reality code is messy for lots of reasons. I'd rather have people contribute and do a bit of gradual cleanup afterwards.

I personally think that code uniformity is highly overrated. It's very easy to be opinionated about and loose valuable time controlling petty details.

So to answer your question:
Yes it would be wise, but it's not something I'm willing to enforce, because there is a trade-off with getting new developers on board whose opinion and expertise is going to be different. I just apply the boy-scout rules: leave the campsite better then it was.

"description": "",
"keywords": [],
"license": "ISC",
Copy link
Contributor

@Keraito Keraito May 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this is the only subproject with a ISC license? From what I could find, there doesn't seem to be a major difference with MIT, but just curious why one folder is differently licensed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No there's no reason, the only reason this is in the PR, is because I auto-sort package.json files.

Please feel free to change it to MIT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
components maintenance User-facing maintenance tasks ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants