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

[core] Remove makeStyles dependency on @material-ui/core/styles #1627

Merged
merged 15 commits into from
May 18, 2021
Merged

[core] Remove makeStyles dependency on @material-ui/core/styles #1627

merged 15 commits into from
May 18, 2021

Conversation

mnajdova
Copy link
Member

@mnajdova mnajdova commented May 11, 2021

Changes done in the PR:

  1. Where there is no use of the theme in makeStyles I just changed the import from @material-ui/core/styles to @material-ui/styles.
-import { makeStyles } from '@material-ui/core/styles';
+import { makeStyles } from '@material-ui/styles';
  1. Where there is theme usage, I've added the defaultTheme arg in the makeStyles options to be the result of createMuiTheme(). If there is another theme in the context, it will be picked up anyway by the makeStyles() util.
-import { makeStyles } from '@material-ui/core/styles';
+import { makeStyles } from '@material-ui/styles';
+import { createMuiTheme } from '@material-ui/core/styles';

+const defaultTheme = createMuiTheme();
 const useStyles = makeStyles((theme) => ({
   backgroundColor: theme.palette.primary.main,
-}));
+}), { defaultTheme });

@oliviertassinari
Copy link
Member

This one is going to be interesting. Data grid supports v4 and v5, which add complexity to this effort. The best option I can think of is to have a implicit transitive dependency on @material-ui/styles and ask v5 users to install the package manually. Why? Because @material-ui/styles is a singleton, a duplication of package in the bundle would mean losing the theme which will be a mess to debug and handle as support requests.

Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

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

Good luck with this one, it will require to make tradeoffs.

@@ -1,5 +1,5 @@
import * as React from 'react';
import { makeStyles } from '@material-ui/core/styles';
import { makeStyles } from '@material-ui/styles';
Copy link
Member

@oliviertassinari oliviertassinari May 11, 2021

Choose a reason for hiding this comment

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

This is the docs for v4, this change is borderline but it can fly. Alternatives are probably worse.

packages/grid/_modules_/grid/components/GridPagination.tsx Outdated Show resolved Hide resolved
@mnajdova
Copy link
Member Author

mnajdova commented May 11, 2021

This one is going to be interesting. Data grid supports v4 and v5, which add complexity to this effort. The best option I can think of is to have a implicit transitive dependency on @material-ui/styles and ask v5 users to install the package manually. Why? Because @material-ui/styles is a singleton, a duplication of package in the bundle would mean losing the theme which will be a mess to debug and handle as support requests.

Don't have a better proposal either. Seems like the best compromised to make it work with both versions... I also think, that v5 users will need to install @material-ui/styles anyway it to as it is used in the components too 😕

@oliviertassinari should we then list @material-ui/styles in peerDependencies too?

@mnajdova mnajdova marked this pull request as ready for review May 11, 2021 16:02
@mnajdova mnajdova requested a review from dtassone May 11, 2021 16:04
@oliviertassinari
Copy link
Member

oliviertassinari commented May 11, 2021

@oliviertassinari should we then list @material-ui/styles in peerDependencies too?

Yeah, sounds good not sure, it would harm the DX for v4 users.

@oliviertassinari oliviertassinari requested a review from DanailH May 11, 2021 16:40
@oliviertassinari
Copy link
Member

Also adding @DanailH as the last one to work on v4/v5 support.

We would need to open the changes in codesandbox and test that v5 works too.

@DanailH
Copy link
Member

DanailH commented May 12, 2021

@mnajdova let me know how I can help with this effort. If I understood the problem correctly it looks like we would need a wrapper like the muiStyleAlpha util.

@mnajdova
Copy link
Member Author

@mnajdova let me know how I can help with this effort. If I understood the problem correctly it looks like we would need a wrapper like the muiStyleAlpha util.

Just pushed the change :D Let me know if it looks correct. I didn't change the docs/ and packages/storybook files, is that correct?

@DanailH
Copy link
Member

DanailH commented May 12, 2021

@mnajdova let me know how I can help with this effort. If I understood the problem correctly it looks like we would need a wrapper like the muiStyleAlpha util.

Just pushed the change :D Let me know if it looks correct. I didn't change the docs/ and packages/storybook files, is that correct?

Yes I don't think we need to change those since they are loaded under v4.

@mnajdova
Copy link
Member Author

@dtassone @DanailH this should be ready for review. Also, see discussion for the dependencies change we will need to make (#1627 (comment)), to be honest not sure what will be the best way going forward. Not sure if it is critical at this moment, but would be good to have a plan on it.

@dtassone
Copy link
Member

not sure I understand why there are 2 styles packages now

import { createMuiTheme, Theme } from '@material-ui/core/styles';
import { makeStyles } from '@material-ui/styles';

I would have expected.

import { makeStyles, createMuiTheme, Theme } from '@material-ui/styles';

@mnajdova
Copy link
Member Author

not sure I understand why there are 2 styles packages now

import { createMuiTheme, Theme } from '@material-ui/core/styles';
import { makeStyles } from '@material-ui/styles';

I would have expected.

import { makeStyles, createMuiTheme, Theme } from '@material-ui/styles';

The @material-ui/styles are the legacy utilities that use JSS. We need to remove them from @material-ui/core. The @material-ui/core@v5.* will no longer have dependency on @material-ui/styles

On the other hand, all theme-related utils, like createTheme need to be part of the core this is why we have this separation.

@dtassone
Copy link
Member

dtassone commented May 13, 2021

It seems that it is halfway done.

So if @material-ui/styles will go, I suggest we add a makeStyles in material-ui/core/styles in v5 that will have a different underlying implementation but the same signature as in V4. That way we are compatible with v4, v5. Just a silent change under the hood. Would that work?

import { makeStyles, createMuiTheme, Theme } from '@material-ui/core/styles';

@mnajdova
Copy link
Member Author

It seems that it is halfway done.

So if @material-ui/styles will go, I suggest we add a makeStyles in material-ui/core/styles in v5 that will have a different underlying implementation but the same signature as in V4. That way we are compatible with v4, v5. Just a silent change under the hood. Would that work?

import { makeStyles, createMuiTheme, Theme } from '@material-ui/core/styles';

We won’t support this API in v5 (at least not as utils from core using emotion), we plan to support the styled() and sx api for customization.

@dtassone
Copy link
Member

It seems that it is halfway done.
So if @material-ui/styles will go, I suggest we add a makeStyles in material-ui/core/styles in v5 that will have a different underlying implementation but the same signature as in V4. That way we are compatible with v4, v5. Just a silent change under the hood. Would that work?
import { makeStyles, createMuiTheme, Theme } from '@material-ui/core/styles';

We won’t support this API in v5 (at least not as utils from core using emotion), we plan to support the styled() and sx api for customization.

We could add it, for compatibility reason, and maybe mark it as deprecated in the first minor or something.
So the grid and other components can be compatible with v4 and v5 without any dependency issue.

@DanailH
Copy link
Member

DanailH commented May 13, 2021

If I'm understanding this correctly the DataGrid component is an expectation to the case where a component needs to be v4 and v5 compatible at the same time, right?

Also, I remember when we were adding the v5 support it was always meant to be temporary and once v5 is released we would migrate the DataGrid fully as well.

If that is the case then we can have it as it is proposed for now and remove the makeStyles once we are fully migrated.

@mnajdova
Copy link
Member Author

We could add it, for compatibility reason, and maybe mark it as deprecated in the first minor or something.
So the grid and other components can be compatible with v4 and v5 without any dependency issue.

I should check whether and how this will be possible, I am not sure if it is trivial change. Even if we add it I would mark it as deprecated, as I don’t think the core should in the long run support this. cc @oliviertassinari @eps1lon for opinion or ideas

@mnajdova
Copy link
Member Author

Also, I remember when we were adding the v5 support it was always meant to be temporary and once v5 is released we would migrate the DataGrid fully as well.

I didn’t know this, I thought the Grid should always support both versions.

@oliviertassinari
Copy link
Member

oliviertassinari commented May 13, 2021

for opinion or ideas

Looking at the thread it seems that we need to precise the direction. It seems that there is confusion around this point: the intent is to progressively remove makeStyles and withStyles. The changes pushed here are meant to meet halfway between the need to drop @material-ui/styles and not to break the data grid for v4 users until v5 is in a beta state. From a timing perspective, I believe that the intended steps were so far:

  • @material-ui/data-grid depends on @material-ui/styles over @material-ui/core for the styles.
  • @material-ui/core v5 removes all dependencies on JSS, JSS is isolated on @material-ui/styles
  • @material-ui/core v5-beta is released
  • @material-ui/data-grid drops support for v4, depends on v5-beta.0.
  • @material-ui/data-grd rewrite the styles to depend on the styled() API with em/sc

Do we want to commit to it?


Regarding making it easy for third-party libraries to transition from v4 to v5, or even supporting them both for a couple of months. It seems that we have 3 options:

  1. rely on @material-ui/styles/makeStyles
  2. rely on @material-ui/core/styled (not sure if it works, but it's likely)
  3. introduce @material-ui/core/makeStyles back in v5 but powered by emotion, not JSS (sc support not possible)

@dtassone
Copy link
Member

dtassone commented May 13, 2021

introduce @material-ui/core/makeStyles back in v5 but powered by emotion, not JSS (sc support not possible)
I would mark it as deprecated

it seems like an option 🤔 .

  • v4 users don't see any issues.
  • when they migrate to v5 and they still use this version of the grid that support both then they will see the deprecation warning? (maybe we could silent it in the grid and leave it for users...)
  • v5 goes live, we refactor the grid and replace makeStyles with styled, and we stop supporting v4 versions?

Another option would be to add the styled api in v4, and use styled in the grid, and silently move to v5.

  • The styled would be the jss implementation, and map to makeStyle
  • This avoids having the old api in v5, and deprecation warning.

@mnajdova
Copy link
Member Author

I will look into adding makeStyles powered by emotion. Definitely deprecated, or even marked as private_?

@mnajdova
Copy link
Member Author

rely on @material-ui/styles/makeStyles

@oliviertassinari seems like this is not possible because of the JSS singleton? Or am I missing something?

@mnajdova
Copy link
Member Author

From the first look, supporting makeStyles with emotion is not that straight forward, especially for the use-cases we have, like overriding styles implemented by styled(), supporting SSR etc.

I did some exploration today - https://codesandbox.io/s/makestyles-with-emotion-zfeyx?file=/src/App.tsx (the solution is inspired by emotion-js/emotion#1853 (comment), only the API is adjusted to our use-cases). The first problem I have is that I cannot override styles defined by the styled() API which is the first use-cases we will have (it may be possible by using ClassName's cx prop not sure it would fly well, as we would need to use it in all core components, and require using provider at top) :( I haven't even started looking into SSR...

Taking into account that this is only needed for like very short period of time (transition), I am not sure how smart it is to invest too much time into making it all work when anyway don't plan to support it in the long run.

So maybe we should look more Option 1 - rely on @material-ui/styles/makeStyles.

Another option would be to add the styled api in v4, and use styled in the grid, and silently move to v5.

The styled would be the jss implementation, and map to makeStyle
This avoids having the old api in v5, and deprecation warning.

styled() and makeStyles() have different APIs, not sure how this would work. Maybe we can first mirgate all codebase (material-ui-x) to use styled() instead of makeStyles() and then we would use the experimentalStyled() in v5?

@oliviertassinari
Copy link
Member

@oliviertassinari seems like this is not possible because of the JSS singleton? Or am I missing something?

@mnajdova I believe that it's option 1, what you have initially pushed in this PR. For the data grid, it seems good enough,

Thanks for exploring option 3. For my perspective, the biggest value of makeStyles powered by emotion would be for members of the community.

Did we consider option 2?

@mnajdova
Copy link
Member Author

Did we consider option 2?

Haven’t tried it yet. Looks like it could be easier then to migrate to the current experimentalStyled().

I didn’t go in this direction, as when we will get to withStyles usages we will then again get in this situation, and replacing it won’t be that simple (what we have currently in core for migrating to emotion). That’s why in the end I think it’s easiest to go with Option 1.

@mnajdova
Copy link
Member Author

@dtassone @DanailH would be great if I can get a review, I need to resolve merge conflicts each time there is a commit on master. Would suggest reviewing with hidden white spaces changes - https://github.com/mui-org/material-ui-x/pull/1627/files?diff=split&w=1

@oliviertassinari
Copy link
Member

oliviertassinari commented May 17, 2021

It works with core v5 👍 https://codesandbox.io/s/material-demo-forked-jl74j?file=/demo.js

@mnajdova
Copy link
Member Author

Resolving last conflicts and merging. Thanks everyone on the input :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants