Material-ui: [List] [Listitem] Theme not updating on muiTheme change

[puranjayjain]

Problem description

• The mui theme is passed using context to down the tree.
• It is controlled by a state in the main parent.

• When the state is changed to switch to light theme to dark (or vice-versa).
  It is not changed for the listitem.
  Every other component's theme is updated, including subheaders.

  Steps to reproduce

• Change state controlling the theme

• Theme changed for all components except <ListItem />

Note: I also tried forceUpdate to update it but it doesn't update to the new state

Versions

• Material-UI: 15.0.1
• React: 15.1.0
• Browser: Chrome 50.0.2661.102

[mbrookes]

@puranjayjain I just tried with the docs site (which uses List for the AppNavDrawer) and this works as expected.

[puranjayjain]

@mbrookes it is true that it works with the docs site since each of the component examples are in a different route so each time there is a route change a new render is triggered for them. However, when the theme change is triggered on the same page/route as the listitem it fails there (this also occurs for dialogs and menuitems)

[mbrookes]

@puranjayjain I was looking at the LeftNav, which _does_ update when the theme changes, however putting a List directly in the theme examples shows the issue.

The problem seems to be that ListItem uses shouldComponentUpdate, which doesn't check context.

The reason forceUpdate doesn't work is:

This will trigger the normal lifecycle methods for child components, _including the shouldComponentUpdate() method of each child._

https://facebook.github.io/react/docs/component-api.html#forceupdate

[puranjayjain]

@mbrookes so what can be the possible solution to this issue? (a workaround will also do for now)

[mbrookes]

@puranjayjain The only thing I can think of is to make a benign manipulation to a prop on ListItem when the theme on context is changed. Hacky, but it should work.

[nathanmarks]

@mbrookes it can be made to check context, it's the 3rd arg

[mbrookes]

@nathanmarks Yes, @puranjayjain was asking for a workaround (I guess to use until this is fixed in a release).

[puranjayjain]

Would it be possible to fix it in a 0.15.xx milestone? Since the list component is to be rewritten in 0.16 anyway

[mbrookes]

@puranjayjain Feel free to submit a PR.

[puranjayjain]

I submitted a pr for the three components where this issue was occurring. The dialog component is still facing this issue but I haven't figured that out yet. Should I open a new issue for that or can we continue to discuss that issue here as well? (if so the title needs an update)

[mbrookes]

@puranjayjain Thanks for the PR. Please open a new issue for dialogue.