-
Notifications
You must be signed in to change notification settings - Fork 54
Conversation
-added switcher for example // TODO it is merging the both themes
Codecov Report
@@ Coverage Diff @@
## master #280 +/- ##
=======================================
Coverage 89.63% 89.63%
=======================================
Files 62 62
Lines 1167 1167
Branches 173 150 -23
=======================================
Hits 1046 1046
Misses 119 119
Partials 2 2 Continue to review full report at Codecov.
|
# Conflicts: # docs/src/routes.tsx
Merging is now happening in the export of the theme's index file instead of the Provider. This is ready for final review. @levithomason @kuzhelov @miroslavstastny |
Are there any real reason to use Possible the better solution will be to use Context API? |
Yeah, we already discussed that the Context API might be a better option in this case. But now that we have mobx integrated already in this PR, and it might be used in other cases, I don't know if we want to remove all that. But yeah, we are adding that dependency without really having actual need for it. I guess we can switch to the Context API if that's what majority of the people think... @kuzhelov @levithomason thoughts? |
Let's hold off merging this until we resolve one more issue. Clicking on a component after having the docs running on the introduction page, changes the font size on all page. See the gif below: It's strange that this is not the same if I directly open some component page in the browser. Will investigate this tomorrow. |
...theme.componentVariables, | ||
[component]: { | ||
...(theme.componentVariables && theme.componentVariables[component]), | ||
[variable]: value, | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kuzhelov please take a look into the changes in this file regarding the componentVariables. It seems to work okay in my opinion, but would like to have your approval on this, as the initial changes were yours. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these changes were made at the moment where there were no mergeThemeVariables
yet - now we should rather reuse this functionality here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the state's componentVariable to store just the variables for the component being rendered, and then I am using the mergeThemeVariables for generating the final componentVariables. Please take a look now.
|
||
const newTheme: IThemeInput = { | ||
componentVariables: theme.componentVariables, | ||
componentVariables, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this means that theme
is only about styles that are provided by CSS-like objects. At the same time, it is possible for theme to provide static CSS styles, and those won't be applied with current implementation. Although I do understand that naively applying them will be a source of the problem as well, still, could you, please, suggest what is our vision for this question?
package.json
Outdated
@@ -88,6 +88,8 @@ | |||
"fela-plugin-rtl": "^1.0.6", | |||
"keyboard-key": "^1.0.1", | |||
"lodash": "^4.17.10", | |||
"mobx": "^5.1.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
another point to rather use React context for achieving the same goal is that currently we have to include mobx to the list of dependencies - while, essentially, this is used only for docs experience (not something that lib consumer is interested in)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just couple of moments that raise my concerns:
- what are the plans to handle theme's static CSS
- do we really need Mobx? Absolutely agree with @layershifter's sentiments, as couple of additional points
- bundle size of Stardust consumed as a library will increase without any good reason for that (as mobx is used in docs only) - it would be much better if we'll consider to introduce default theme instead for much smaller size cost :)
- even the amount of code necessary will be much lesser if we will use React Context
- there is no immediate need to use Mobx to solve other problems of the library - and in case if there will be any, it is quite straightforward to integrate Mobx when the problem will shape itself, rather than just trying to predict the problems by advertising tool.
…ables for the component styling at that moment -on opening the variables form the merged variables from the theme as well as the state's variables are shown: fixing current issue where the rendered element does not corresponds with the variables values shown in the form
Mobx is now replaced with react context API. Also, fixed bug for not synchronized form values with variables applied in the example. I hope this is ready now for final review. |
@@ -23,17 +23,21 @@ import ComponentExampleTitle from './ComponentExampleTitle' | |||
import ContributionPrompt from '../ContributionPrompt' | |||
import getSourceCodeManager, { ISourceCodeManager, SourceCodeType } from './SourceCodeManager' | |||
import { IThemeInput, IThemePrepared } from 'types/theme' | |||
import { mergeThemeVariables } from '../../../../../src/lib/mergeThemes' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -123,6 +129,10 @@ class ComponentExample extends React.PureComponent<IComponentExampleProps, IComp | |||
) { | |||
this.clearActiveState() | |||
} | |||
const { themeName } = nextProps | |||
if (this.state.themeName !== themeName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a bit unsure - do we really need to store themeName
as state?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, this was changed when the name of the theme was fetch from the mobx store, the themeName prop should be enough now. Will change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I got it now. This was added because we want to invoke renderSourceCode if the themeName prop is changed. Since we are invoking this method here, we need to have a way to get the new themeName, that's why I have it in the state as well. Any other idea about how can we achive this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, yes - but just to unblock the PR, we could make a notch, merge it and I will try to experiment on that further. To me themeName
has clear immutable semantics (that is not example-specific - and this is a key difference from other ones, like showRtl
, for example), so this is the reason I'd rather see it being introduced as prop
@@ -346,10 +356,14 @@ class ComponentExample extends React.PureComponent<IComponentExampleProps, IComp | |||
private getDisplayName = () => this.props.examplePath.split('/')[1] | |||
|
|||
private renderWithProvider(ExampleComponent) { | |||
const { showRtl, theme } = this.state | |||
const { showRtl, componentVariables } = this.state | |||
const { themeName } = this.state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: these two lines could be merged into one. However, concerned whether themeName
should be part of state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented on previous comment.
@@ -540,7 +554,10 @@ class ComponentExample extends React.PureComponent<IComponentExampleProps, IComp | |||
</Divider> | |||
<Provider.Consumer | |||
render={({ siteVariables, componentVariables }: IThemePrepared) => { | |||
const variables = componentVariables[displayName] | |||
const mergedVariables = mergeThemeVariables(componentVariables, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we merge them again here? May be missing something, but it seems that we already merged these variables on line 364, so they will be consumed as already merged ones
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me also lot of time to figure this out, but this consumer is for the root Theme Provider, where in contrast, the example, uses it's own provider where these are merged (overriden). This is why we actually have previously bug where the componentVariables were not reflecting the latest status of the variables applied on the example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it - still, see it to be a problem that we are merging in two different places of the ComponentExample code. Let me take a look on that after PR will be merged
> | ||
<NewApp /> | ||
</Provider> | ||
<NewApp /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just to clarify for myself - could you, please, suggest what was the reason of moving (and augmenting) this theme context functionality from here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was also moved because of the Mobx initial implementation, but I still think the logic for the new Theme context and the Provider should reside in some component file, rather then here. What are your thoughts on this? Maybe the better approach would be creating an App component for all these rather then having them in the routes, but anyway I would like them in some component logic...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plus we are using state for the theme context, so we must have some component as a wrapper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason I see the initial implementation as being more semantically correct is that because routes
file will correspond to the app-related aspects, and theming context is something that is not closely related to it. This is a subtle question and I cannot state anything here, but would rather omit these changes from the PR for now. Please, feel free to decide by yourself, though :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Introduced App component that will hold the logic for providing the theme context and the provider.
-reverted commenting of the merged variables in the variables panel
Docs - theme switcher
This PR is adding the switching theme feature on the docs site. For this to work, the following things are implemented:
Mobx is added as a dependency for storing the currently selected theme (we are storing just the name of the theme here)
Dropdown menu is added on the sidebar, where all exported themes are displayed as options.
Two additional themes are added: teams dark and teams high contrast theme. These themes are simple and are just adding some styling for the button component, so that we can showcase the theme switching.
The selected theme is merged with the teams default theme in the root Provider of the docs.
Demo: