Deprecate/remove ThemeProvider in favor of theming?

[kentcdodds]

@iamstarkov created a new library called theming (with help from many folks, including @vesparny who built our implementation). It's intended to unify theming for React CSS in JS libraries. I'm in support of this effort and would like to propose we consider deprecating/removing our own ThemeProvider in favor of documenting an integration with theming. Here's our current Theming example which uses theming instead of glamorous.ThemeProvider. Works great.

An alternative would be that we remove our own implementation and just use theming. This would be totally unobservable to developers using glamorous and everything would keep working the same. I say we at least do this.

Thoughts?

[iamstarkov]

as far as glamorous offers theming support beyond ThemeProvider and withTheme, you need deeper theming integration as we discussed in cssinjs/theming#3. That said, you need to re-export theming from within glamorous, so breaking changes for deep integration and for themeProvider/withTheming will be happening at the same time, so it will be in sync.

[iamstarkov]

regarding "breaking change" badge, i wouldnt agree. theming has the same surface api for the consumers as glamorous's implementation. The only different part is channel, but to address that there is createTheming to create theming with custom channel.

// ./src/theming.js
import { createTheming } from `theming`;

export const { ThemeProvider, withTheme } = createTheming('__glamorous__');

and its not breaking change anymore

[kentcdodds]

I don't think that glamorous needs more than what we get with ThemeProvider and withTheme. So I'm thinking that we could do as you suggest and remove our own implementation.

I'm actually thinking that instead of use createTheming with __glamorous__ was just use the default. That way we would interop well with anyone else using theming which I think would be cool (and is really the dream right?)

[iamstarkov]

related https://github.com/cssinjs/react-jss/pull/95

[iamstarkov]

I'm quite sure glamorous is using theming beyond themeprovider and withtheme. Just take a look at theming examples https://github.com/paypal/glamorous/blob/master/README.md#theming

const Title = glamorous.h1({
  fontSize: '10px'
}, (props, theme) => ({
  color: theme.main.color
}));

Theme here is not a prop and component is not wrapped into withtheme

[iamstarkov]

Though, I might be wrong

[kentcdodds]

Ah, I see what you mean. Yes, we return a component which we would ourselves wrap in withTheme 👍

[iamstarkov]

@vesparny what do you think?

[vesparny]

I am from mobile now. will read all the thread and reply as soon as possible

[vesparny]

I think we have 2 options:

1. We remove theming from glamorous, and we encourage people to use theming if they need to
2. We remove our own implementation from glamorous, and we replace it with theming

It would be really helpful to know if the community uses <ThemeProvider /> a lot.
In that case option 2 would probably be the best one.

I'd personally go for option 1 because I do not always need theming capabilities in my apps.

By removing it we can also shave off some bytes from glamorous, which is always good :)

On the other hand option 2 is the easiest and less invasive one (not a breaking change at least)

[kwelch]

I really like the ability to theme, but the argument for bytes is valid. What if glamorous implemented theming, and glamorous.tiny trimmed it as it is more appealing to those saving bytes?

[kentcdodds]

I say let's go with option 2. Anyone who cares enough about size will be tree shaking anyway and that will be just like we didn't have theming at all. Option 2 will simplify our codebase, so that'll be nice. Anyone want to open up a pull request for this?

[vesparny]

That would be a nice one for first time contributors 😃
Otherwise I can take it

[kentcdodds]

Unfortunately I don't think it'll be totally straightforward. But if you'd like to outline exactly what needs to be done, then we can guide a first time contributor on this one which would be super!

[vesparny]

@kentcdodds uhm...you are probably right.

I think as first step we can try to replace our ThemeProvider and withTheme with the ones exported by theming in tests and see what happens.

[vesparny]

Ideally we would also remove those lines and use withTheme instead.

cc @iamstarkov

[iamstarkov]

@vesparny for that particular use case where theming functionality is baked in into ComponentFactory we would need themeListener from cssinjs/theming#3

[kentcdodds]

Hmmm... I'm unsure I understand. We could just remove those lines and use withTheme around the GlamorousComponent instead right? Aren't those lines what withTheme is supposed to take care of for us? In fact, without those lines GlamorousComponent could just be a function component I think...

[iamstarkov]

@kentcdodds if i am correct, then right now GlamorouseComponent is exactly one component. if we would wrap it into withTheme, then it becomes exactly two, so if the app is built entirely with glamorous, then we double amount of components in react tree and in dev tools, which seems to me like an overkill. Instead, we can integrate themeListener which will receive initial theme and any theme updates inside of GlamorousComponent and then GlamorousComponent will proceed as before. So themeListener will abstract implementation details of theming support for GlamorousComponent

I'll show what i mean shortly

[kentcdodds]

Actually, a GlamorousComponent is uniquely created for every time you call glamorous.div() so we're at the same spot either way :)

[iamstarkov]

well, "shortly" was a exageration, maybe tomorrow morning

[kentcdodds]

I've been implementing this and I now know what you meant. But don't worry about, my implementation actually makes it so we don't add another component into the tree :)

[kentcdodds]

Please see #184, I think we'll need theming to support some of this stuff if we want to use it.

[kentcdodds]

Ok, so #184 has been merged, so we're ready to do this as soon as we get these two things implemented: cssinjs/theming#13 cssinjs/theming#14 👍

[iamstarkov]

@vesparny can you take a look as well in cssinjs/theming#3 and how it can help here?

[vesparny]

@iamstarkov I took a look at your implementation and looks very good to me.
Only difference I see is that on Glamorous we set theme also based on props.
For instance if you pass a theme prop to a component, it takes precedence over the one stored in context.

glamorous/src/with-theme.js

Lines 37 to 40 in 0bfda9f

	this.setTheme(theme ? theme : this.context[CHANNEL].getState())
	} else {
	this.setTheme(theme || {})
	}

What happens in the same case with theming?

[kentcdodds]

I'm going to go ahead and close this unless it comes up again and would simplify things for us. Thanks!

[goodmind]

@kentcdodds why this is closed?

[kentcdodds]

Because theming doesn't quite support our use cases. Specifically this. I kinda doubt that theming will be changed to support that. But if that happens that'd be great :)

[kentcdodds]

We'd like to re-evaluate this and see if we can make it work.

[kentcdodds]

I think this would be great, but I'm honestly not too motivated to do this personally. If anyone else wants to pick it up be my guest and we can reopen it. Thanks!