In existing projects there might be components that already has the theme prop. Also, sometimes a component only cares about parts of the theme. Maybe provide an option to send in a mapping function just like how connect in react-redux works?

withTheme(theme => {theTheme: theme})(Component)
withTheme(theme => {primaryColor: theme.palette.primary})(Component)

The current playground demo is inaccessible at WebpackBin, because the site is being deprecated in favor of CodeSandbox. I was able to find the source code here, but it wasn't runnable. So, I created a sanbox instead. Let's update the link if the demo is still applicable.

P.S. There's a small inconsistency, when you switch to alternate theme, round (border radius) changes to 10, whereas in the gif, it remains at 0.

Thanks

I really have no idea what's going on. But when I tried hooking this up with glamorous here I'm getting:

TypeError: createBroadcast is not a function
    at new ThemeProvider (dll.js:formatted:20246)
    at dll.js:formatted:9691
    at measureLifeCyclePerf (dll.js:formatted:9575)
    at ReactCompositeComponentWrapper._constructComponentWithoutOwner (dll.js:formatted:9690)
    at ReactCompositeComponentWrapper._constructComponent (dll.js:formatted:9683)
    at ReactCompositeComponentWrapper.mountComponent (dll.js:formatted:9638)
    at Object.mountComponent (dll.js:formatted:1790)
    at ReactCompositeComponentWrapper.performInitialMount (dll.js:formatted:9724)
    at ReactCompositeComponentWrapper.mountComponent (dll.js:formatted:9670)
    at Object.mountComponent (dll.js:formatted:1790)

The problem is in this file.

It's tricky debugging in codesandbox, but this is what the code looks like:

You'll see that I have a breakpoint on where we're requiring createBroadcast but that breakpoint never hits and it hits the _this.broadcast = ... line first. Quite odd. Not sure what's going on here.

I was wondering if this repository is still maintained.

This issue is part of a series of feedbacks. I been upgrading the Material-UI solution.
Unfortunately, I had to fork the package in order to reach my goal.
Now, it's time to reconciliation.

The issue

I have noticed that a theme callback can be called twice during a first render.
The first time, it's called with a null outer theme.
I think that it can be reproduced with the following:

<ThemeProvider theme={x}>
  <ThemeProvider theme{(x) => { console.log(x) }>
    <div />
  </ThemeProvider>
</ThemeProvider>

Would you consider adding an hook to update the theme ?

Due to brcast issue - vesparny/brcast#7

This library is used in react-jss and material-ui alpha and I'm receiving error from webpack's uglify.

@oliviertassinari @kof

This is what we do in glamorous.

This has the benefit of the component effectively serving as the render method of your ThemeComponent which has various benefits (one of which being performance).

We use this for all glamorous components via an option: withTheme(Comp, {createElement: false}) (createElement defaults to true).

Right now, glamorous allows you to specify your own context:

const MyDiv = glamorous.div()
MyDiv.contextTypes = {/* blah */}

Normally, this would override the contextTypes needed for MyDiv to have access to the theme, but we do something like this:

const defaultContextTypes = {
  [CHANNEL]: PropTypes.object,
}

let userDefinedContextTypes = null

// configure the contextTypes to be settable by the user,
// however also retaining the glamorous channel.
Object.defineProperty(GlamorousComponent, 'contextTypes', {
  enumerable: true,
  configurable: true,
  set(value) {
    userDefinedContextTypes = value
  },
  get() {
    // if the user has provided a contextTypes definition,
    // merge the default context types with the provided ones.
    if (userDefinedContextTypes) {
      return {
        ...defaultContextTypes,
        ...userDefinedContextTypes,
      }
    }
    return defaultContextTypes
  },
})

It's a bit hacky and kinda "clever"

I wonder if this is something the withTheme component could support. It's a requirement for paypal/glamorous#175 to be implemented without being a breaking change...

I see there is no UMD bundle at the moment (https://unpkg.com/[email protected]/dist/)

Would it make sense to have one? I think without it people not using a bundler won't be able to use theming (mainly because dependencies are not bundled in cjs/es dist files)

@kentcdodds what do you think? I'm a little bit lost when I have to deal with dist files :)

I was reviewing the documentation for theming at this link https://github.com/cssinjs/theming#themeprovider and the codesandbox sample is not found.

please add a demo example how we can implement toggle theme light to dark etc

• Documentation
• Example
• Playground
• Add tests for withTheme

Main issue cssinjs/jss#488

From Reademe:

Playground demo
Be our guest, play with theming in codesandbox: https://codesandbox.io/s/jvwzkkxrp5

Using the ThemeProvider like so:

import { ThemeProvider } from "theming";

<ThemeProvider theme={myTheme}>
    <App />
</ThemeProvider>

Gives the following compile error:

[ts] JSX element class does not support attributes because it does not have a 'props' property. [2607]
[ts] Property 'theme' does not exist on type '{}'. [2339]

Also making the options optional on the withTheme would be great.

export default withTheme(injectSheet(styles)(App), {
  forwardInnerRef: true // <--- this
});

Broke in the newest version 2.1.0.

The Sandbox url is death .

This issue is part of a series of feedbacks. I been upgrading the Material-UI solution.
Unfortunately, I had to fork the package in order to reach my goal.
Now, it's time to reconciliation.

The issue

It would be awesome if we could be supporting a default theme.
That's something I have been implementing on Material-UI in order to reduce onboarding friction.

This is what we do in glamorous

function generateWarningMessage(Comp) {
  const componentName = Comp.displayName || Comp.name || 'FunctionComponent'
  // eslint-disable-next-line max-len
  return `glamorous warning: Expected component called "${componentName}" which uses withTheme to be within a ThemeProvider but none was found.`
}
// ...

// ...
    componentWillMount() {
      if (!this.context[CHANNEL]) {
        if (process.env.NODE_ENV !== 'production' && !this.warned) {
          this.warned = true
          // eslint-disable-next-line no-console
          console.warn(generateWarningMessage(ComponentToTheme))
        }
      }
// ...

I'd also love it if this could be disabled. For GlamorousComponents, they all need to be themeable, but not always will they be inside a ThemeProvider (you can pass the theme/override via props). So in glamorous we also accept options: withTheme(Comp, {noWarn: true}).

As title says! :)

Would it make sense for the JSS ThemeProvider to not only accept theme but also colorScheme or mode?

https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

I've seen some handle it this way, but it doesn't seem clean enough, IMO.

Hey there,

I'm getting the following in my console:

$ yarn list react
yarn list v1.0.1
├─ [email protected]
└─ [email protected]
   └─ [email protected]

Any idea why theming might be keeping around an extra copy of react? Thanks!

This issue is part of a series of feedbacks. I been upgrading the Material-UI solution.
Unfortunately, I had to fork the package in order to reach my goal.
Now, it's time to reconciliation.

The issue

I found that the theme is no longer correctly propagated when we nest more than 2
ThemeProvider. It can be seen in the implementation of create-theme-provider.js.
setState() is never called on the child broadcast after receiving a parent theme update.

I have a component like so:

import * as React from "react";
import { withTheme, ThemeProviderProps } from "theming";
import injectSheet, { StyledComponentProps, StyleCreator } from "react-jss";

import { ITheme } from "../../whitelabel/theme";

export interface ILogoProps
  extends StyledComponentProps,
    ThemeProviderProps<ITheme> {
  condensed?: boolean;
}

const Logo: React.SFC<ILogoProps> = ({ classes, condensed = true, theme }) => {
  const logo = condensed
    ? theme.branding.logo.sidebar.condensed
    : theme.branding.logo.sidebar.original;
  return <img src={logo} className={classes.root} />;
};

const styles: StyleCreator = (theme: ITheme) => ({
  root: {
    display: "block",
    height: 40
  }
});

export default injectSheet(styles)(withTheme(Logo));

When I use this component from another component, e.g.:

import * as React from "react";
import Logo from "./logo";

export default class Sidebar extends React.Component  {
  public render() {
    const { expanded } = this.state;
    return <Logo condensed={!expanded} />
  }
}

I get a TypeScript error saying:

[ts] Property 'condensed' does not exist on type 'IntrinsicAttributes & Pick<(Pick<{ theme: object; }, "theme"> & { theme?: object; innerRef?: (ref: StatelessComponent) => void; }) | (Pick<{ theme: object; }, "theme"> & { ...; } & { ...; }), never> & StyledComponentProps<...> & { ...; }'. [2339]

If I switch the withTheme(...) to wrap like export default withTheme(injectSheet(styles)(Logo)); the same error arrives on that line.

Am I doing something wrong?

I have created a new themeable wrapper for my components but I would like to extend the Material-UI theme so I can have access to it's properties like palette and spacing

import injectSheet, { createTheming } from 'react-jss';

export const theming = createTheming('__EVENT_GIVES_THEME__');
export const { ThemeProvider: Themable } = theming;

export default (styles) => injectSheet(styles, { theming });

This is my current setup. All components are rendered within an app layout like so

<Provider store={store}>
  <MuiThemeProvider theme={theme}>
    <div>
      <Reboot />
      <AppRouter />
    </div>
  </MuiThemeProvider>
</Provider>

But I guess because of the new theme I created it's not inheriting any of this?

An example of how I'm using this if it helps understand is I have three files with each component, a wrapper that applies the theme and styles, a component file with the actual component and then a styles file where I put all my classes. Here is what one looks like

QuantityInput.styles.js

import { merge } from 'lodash';

const styles = theme => {
  return merge({
    quantityInput: {
      color: theme.palette.primary,
      fontWeight: '400',
      fontSize: '13px',
      display: 'inline-block',
      textAlign: 'center',
      top: '10px',
      float: 'left',
      width: '35px',
      position: 'relative'
    }
  }, theme);
};

export default styles;

**QuantityInput.jsx**

import React from 'react';
import QuantityInputComponent from './QuantityInput.component';

import { Themable } from '../Themable';

const QuantityInput = ({ theme, ...rest }) => (
  <Themable theme={theme || {}}>
    <QuantityInputComponent {...rest} />
  </Themable>
);

export default QuantityInput;

QuantityInput.component.jsx

import React from 'react';
import styles from "./QuantityInput.styles";
import IconButton from 'material-ui/IconButton';
import RemoveIcon from 'material-ui-icons/Remove';
import AddIcon from 'material-ui-icons/Add';

import themableWrapper from '../Themable';

const QuantityInputComponent = (props) => (
  <div className="quantity-selector">
    <IconButton aria-label="Remove">
      <RemoveIcon />
    </IconButton>
    <span className="quantity-wrap">
      <input name="quantity" type="number" className="quantity" />
    </span>
    <IconButton aria-label="Add">
      <AddIcon />
    </IconButton>
  </div>
);

export default themableWrapper(styles)(QuantityInputComponent);

One of the annoyances of HoCs is that they add a level of hierarchy to the React Component tree. This has perf and DX implications. In the case of glamorous, every component is wrapped in our own withTheme HoC, but the way we do it side-steps the issue. Here's a basic example of what we do:

function hoc(TheComponent, {createElement = true}) {
  return class HOC extends React.Component {
    render() {
      if (createElement) {
        return <TheComponent {...this.props} {...this.state} />
      }
      return TheComponent.call(this, {...this.props, ...this.state}, this.context)
    }
  }
}

const MyWrappedComponent = hoc(function MyComponent(props, context) {
  this.someNonRenderStateStuff = {/* we use this to keep track of instance info */}
  return <div>blah</div>
}, {createElement: false})

If theming could support this and handle #12, then that would be awesome and we can switch 🎉

It doesn't even have to be a documented feature. We don't document it about our withTheme HoC because I see it as an implementation detail to get improved performance and developer experience.

Thoughts?

My app allows an admin to switch between different users. Each user has a different theme, which is applied when the admin switches. It does so via a component I made, WhitelabelProvider, which is nested inside of React Router's BrowserRouter component.

My WhitelabelProvider contains your library's Theme Provider, and renders it like so:

  render() {
    const { children } = this.props;
    const { theme } = this.state;

    return (
      <ThemeProvider theme={theme}>
        <div className="ThemedApp">
          <Favicon url={theme.app.favicon.src} />
          {children}
        </div>
      </ThemeProvider>
    );
  }

The remainder of the routes and components are rendered via the children prop.

I'm finding that, when changing themes, certain components, all of which use withTheme, are displaying warnings like so:

index.js:2177 Warning: Can only update a mounted or mounting component. This usually means you called setState, replaceState, or forceUpdate on an unmounted component. This is a no-op.

Please check the code for the WithTheme(styled.div) component.

Am I somehow using ThemeProvider or WithTheme incorrectly? Any help is appreciated, and I'm happy to provide more context if needed.

Some relevant package.json entries:

"react": "^16.1.1",
"styled-components": "^3.2.3",
"theming": "^1.3.0"

I just thought about replacing the theming helpers in fela with this unified approach. Sadly it only supports React and we have to serve something for Preact and Inferno as well.
(robinweser/fela#302)

What do you think about extracting the abstract parts and compose them to several packages such as React, Preact, Inferno and maybe even more?

there are two problems:

• docs might have typos and grammar mistakes, because English is not my native language
• docs might have logic flaws and be unintuitive for other developers_, because I am knee deep in this project, so I understand everything and it seems easy for me, so I struggle to understand what is missing in documentation.

So I need help from native speakers and from developers who are new to this project