Version 10.8.1 release looks incompatible with 10.8.0.

mfaheemakhtar commented 3 years ago

Expected behavior: Things should work.

Describe the bug: I am using MUI v5 and using a theme that is using jss in style provider. The theme uses @mui/styles which is depreciated for mui5 but was working fine. I am also using data-grid.

The recent release of 10.8.1 caused the app to break when a screen with data-grid is viewed. I spent multiple hours to find that there are different versions of jss and plugins in the yarn.lock, and 10.8.0 and 10.8.1 does not seem to go together because of replaceUrl or something.

Did some tweaking but then there was a type issue. I don't know where the problem is and I could not find anything so I am posting it here. The problem is probably not with the package itself but a unique combination of different packages with different versions of jss and plugins.

Reproduction:

Unfortunately, I was not able to reproduce it outside of the project. May try on weekends if got time.

Versions (please complete the following information):

jss: 10.8.1
Browser [e.g. chrome, safari]: Brave
OS [e.g. Windows, macOS]: Windows 10 Pro, Ubuntu 20.x
@mui/styles: 5.0.0
@mui/x-data-grid-pro": "^5.0.0-beta.2" Feel free to add any additional versions which you may think are relevant to the bug.

Managing expectations:

Maintainers will not be fixing the problem you have unless they have it too, if you want it to get fixed:

Submit a PR with a failing test
Discuss a solution
Implement it

You can also do the first step only and wait for someone else to work on a fix. Anything is much better than nothing.

I am short of time at the moment and can't really provide anything right now, maybe I can try to reproduce on weekends if I get time.

The yarn resolutions fixed the issue for me:

"resolutions": {
    "jss": "10.8.0",
    "jss-plugin-camel-case": "10.8.0",
    "jss-plugin-default-unit": "10.8.0",
    "jss-plugin-global": "10.8.0",
    "jss-plugin-nested": "10.8.0",
    "jss-plugin-props-sort": "10.8.0",
    "jss-plugin-rule-value-function": "10.8.0",
    "jss-plugin-vendor-prefixer": "10.8.0"
  }

If someone else face the similar issue, try this.

viko16 commented 3 years ago

+1

10.8.1 changed the output of nested styles, now it is can't generate correct nested and dynamic className

That's my case: https://codesandbox.io/s/amazing-rain-ut7q1?file=/src/App.js

kabdelkareem commented 3 years ago

+1 we have the same issue. it caused issues in material-ui styles

seiyab commented 3 years ago

Extending number of items to 10, https://github.com/cssinjs/jss/issues/1565#issuecomment-947407480 shows 2nd, 5th, and 8th items render wrong style. react-jss might accidentally generates same key for different rules and they are replaced by update of other rules.

kof commented 3 years ago

@seiyab do you see an easy fix?

seiyab commented 3 years ago

@kof Not yet. I would read react-jss codes. I found that react-jss might still cause memory leak. I peeked RuleList that https://github.com/cssinjs/jss/issues/1565#issuecomment-947407480 generates. It generates more rules on rerendering component. I should have added rerendering test for react-jss.

kof commented 3 years ago

Let me know if we should revert the change for now and release a previous version as a patch

mfaheemakhtar commented 3 years ago

@seiyab, not sure if it is helpful but the style of tiem number 2 in @viko16 is missing because of this line in jss removes the style from the cssRules.

//_proto.replaceRule
this.cssRules.splice(index, 1);

But this line only inserts the new rule in the container styles and not in the cssRules

return this.insertRule(rule, index);

This makes the _proto.refCssRule function to replace the wrong item in the array because the element to be removed is not inserted yet?

if (rule.options.parent instanceof StyleSheet) {
      this.cssRules[index] = cssRule;
}

TLDR: The old rule was at index 4. Splice removed it. Now next style (of item 2) is at index 4. Insert should add the new rule in cssRule at index 4, So style of 2 gets back to 5 again. At last style at index 4 (which was 5 initially) gets replaced by new rule.

Potential Solutions:

Don't remove from this.cssRules because it will eventually get replaced later. I don't know it will work.

My breakpoints

seiyab commented 3 years ago

It seems to be better to revert 10.8.1 because #1565 is more serious than #1360 .

@mfaheemakhtar Thanks a lot. It will help.

seiyab commented 3 years ago

Perhaps

this.cssRules[index] = cssRule

should be

this.cssRules.splice(index, 0, cssRule)

However, it still render rules in different order between RuleList and style. I use following test case and it went wrong.

sheet = jss
  .createStyleSheet(
    {
      a: ({color}) => ({
        color: 'red',
        '& a': {
          color
        }
      }),
      b: ({display}) => ({
        display: 'block',
        '& b': {
          display
        }
      })
    },
    {link: true}
  )
  .attach()

mfaheemakhtar commented 3 years ago

I will do some more debugging tomorrow and compare 10.8.0 and 10.8.1. I will also take a look at what changed in tests.

kof commented 3 years ago

please somebody add a failing test for this new problem

seiyab commented 3 years ago

I submitted PR https://github.com/cssinjs/jss/pull/1571 that adds a failing test for this problem.

Additionally, I wrote behavior for each version in branch for experiment. https://github.com/seiyab/jss/blob/67eb962900910a4d675f71480d6285fe19dfdc04/packages/react-jss/src/createUseStyles.test.js#L79-L282 Both v10.8.0 and v10.8.1 renders wrong style. and v10.8.1 is more serious. v10.8.0: generates more and more rules on update. v10.8.1: rules can be replaced by another rule on update.

Replacing this.cssRules[index] = cssRule by this.cssRules.splice(index, 0, cssRule), perhaps it is resolved. https://github.com/seiyab/jss/blob/67eb962900910a4d675f71480d6285fe19dfdc04/packages/react-jss/src/createUseStyles.test.js#L284-L370

kof commented 3 years ago

if this.cssRules.splice(index, 0, cssRule) is fixing the problem, should we release the fix then rather than reverting?

seiyab commented 3 years ago

In my opinion, reverting as first aid is a safer option. Reasons:

I missed another problem replaceRule is not a function https://github.com/mui-org/material-ui/issues/29162#issuecomment-946717169 .
It might be better to add more test cases to make sure that the fix doesn't break existing features and the fix also works with react-jss.

kof commented 3 years ago

I see, alright, reverting now

kof commented 3 years ago

Patch released https://github.com/cssinjs/jss/releases/tag/v10.8.2