Enhancing the theme using material-ui@next and typescript

Question

Enhancing the theme using material-ui@next and typescript

While developing my theme using material-ui, I decided to introduce two new palette options that would offer a wider range of light and dark shades. To achieve this, I extended the Theme type with the necessary modifications:

import {Theme} from "material-ui/styles";
import {Palette} from "material-ui/styles/createPalette";

export interface ExtendedTheme extends Theme {
    palette: ExtendedPalette
}

export interface ExtendedPalette extends Palette {
    light: Color,
    dark: Color,
}

The complication arises when attempting to apply these additional options within the WithStyles render helper:

const styles = (theme : ExtendedTheme) => ({ root: {color: theme.light['100'] }});

export interface MyProps {classes: {[index: string] : string}};
const MyComponent = (props : MyProps) => {...};

// Type ExtendedTheme is not assignable to Theme
export default withStyles(styles : StyleRulesCallback)(MyComponent);

Despite the functional success of my code in pure javascript, it encounters an error due to the mismatched types. The material-ui typings are set up to expect only the Theme type as the argument for the style callback function:

export type StyleRulesCallback<ClassKey extends string = string> = (theme: Theme) => StyleRules<ClassKey>;

I initially believed that extending an interface would allow for polymorphic implementation, where ExtendedTheme would seamlessly incorporate Theme.

javascript typescript material-ui

Answer 1

Answer №1

To overcome the issue, one can utilize module augmentation:

declare module '@material-ui/core' {
  interface Theme {
    colors: {
      success: {
        dark: string,
        light: string,
      }
    }
  }
}

Additionally, it is advisable to define the module within the App component while encapsulating the children in a ThemeProvider:

import { createMuiTheme, ThemeProvider, colors, ThemeOptions } from '@material-ui/core';

declare module '@material-ui/core' {
  interface Theme {
    colors: {
      success: {
        dark: string,
        light: string,
      }
    }
  }
}

const App = () => {
  const theme = createMuiTheme({
    colors: {
      success: {
        dark: colors.green[600],
        light: colors.green[300],
      },
    } as ThemeOptions,
  });

  return (
    <ThemeProvider theme={theme}>
     <a href="https://material-ui.com/customization/theming/">Theming</a>
    </ThemeProvider>
  )

Answer 2

To overcome the issue, one can utilize module augmentation:

declare module '@material-ui/core' {
  interface Theme {
    colors: {
      success: {
        dark: string,
        light: string,
      }
    }
  }
}

Additionally, it is advisable to define the module within the App component while encapsulating the children in a ThemeProvider:

import { createMuiTheme, ThemeProvider, colors, ThemeOptions } from '@material-ui/core';

declare module '@material-ui/core' {
  interface Theme {
    colors: {
      success: {
        dark: string,
        light: string,
      }
    }
  }
}

const App = () => {
  const theme = createMuiTheme({
    colors: {
      success: {
        dark: colors.green[600],
        light: colors.green[300],
      },
    } as ThemeOptions,
  });

  return (
    <ThemeProvider theme={theme}>
     <a href="https://material-ui.com/customization/theming/">Theming</a>
    </ThemeProvider>
  )

Answer 3

Answer №2

After pondering the issue, I have found a solution to address my custom options in a more flexible manner.

export interface ExtendedPalette extends Palette {
    light?: Color,
    dark?: Color,
}

In order to handle these additional options within my styles callback, I must verify their existence, which can be somewhat tedious. Yet, I believe this is the most optimal approach available.

const styles = (theme : ExtendedTheme) => { 
    let light = theme.palette.light[100];
    if(light === undefined) light = theme.common.white;
    { root: {color: light }}
};

The challenge arises from the fact that while the Theme object is provided to the callback through the use of withStyles, the typings for this callback specify the Theme type since they are unaware of my ExtendedTheme type. The conflict occurs when ExtendedTheme includes options that are unknown to Theme. By making these extra options optional, it allows Theme to remain compliant with ExtendedTheme. Essentially, an extended interface can be substituted where its parent is anticipated, but not vice versa unless the extension ensures compatibility with the parent.

An example may help illustrate this concept further.

export interface Foo {foo: string};
export interface Bar extends Foo {bar: string}

function getFoo(f : Foo) {console.log(f.foo)}
function getBar(b : Bar) {console.log(b.bar)} 
function getFooBar(fb: Bar) {console.log(fb.foo, fb.bar)}

const f : Foo = {foo: 'foo'}
const b : Bar = {foo: 'foo', bar: 'bar'}

getFoo(f) // foo
getFoo(b) // foo
getBar(f) // Error Incompatible Type
getBar(b) // bar
getFooBar(f) // Error Incompatible Type
getFooBar(b) // foo bar

getFoo(b) functions correctly because Bar necessarily includes all properties of

Foo</code. On the other hand, both <code>getBar(f)

and getFooBar(f) fail due to the absence of the key bar in the Foo type.

If we redefine Bar as follows:

export interface Bar extends Foo {bar? : string}

The compiler acknowledges that Foo meets the minimum requirements for the Bar type. However, it is important to account for potential null values. As a result, the following adjustment enables successful execution:

getBar(f)

Nevertheless, the presence of implicit nulls prompts the compiler to issue warnings. This necessitates modifying the function accordingly:

function getBar(b : Bar) {
    let bar = b.bar
    if(bar === undefined) bar = b.foo;
    console.log(bar);
}

getBar(b) // bar
getBar(f) // foo

Answer 4

After pondering the issue, I have found a solution to address my custom options in a more flexible manner.

export interface ExtendedPalette extends Palette {
    light?: Color,
    dark?: Color,
}

In order to handle these additional options within my styles callback, I must verify their existence, which can be somewhat tedious. Yet, I believe this is the most optimal approach available.

const styles = (theme : ExtendedTheme) => { 
    let light = theme.palette.light[100];
    if(light === undefined) light = theme.common.white;
    { root: {color: light }}
};

The challenge arises from the fact that while the Theme object is provided to the callback through the use of withStyles, the typings for this callback specify the Theme type since they are unaware of my ExtendedTheme type. The conflict occurs when ExtendedTheme includes options that are unknown to Theme. By making these extra options optional, it allows Theme to remain compliant with ExtendedTheme. Essentially, an extended interface can be substituted where its parent is anticipated, but not vice versa unless the extension ensures compatibility with the parent.

An example may help illustrate this concept further.

export interface Foo {foo: string};
export interface Bar extends Foo {bar: string}

function getFoo(f : Foo) {console.log(f.foo)}
function getBar(b : Bar) {console.log(b.bar)} 
function getFooBar(fb: Bar) {console.log(fb.foo, fb.bar)}

const f : Foo = {foo: 'foo'}
const b : Bar = {foo: 'foo', bar: 'bar'}

getFoo(f) // foo
getFoo(b) // foo
getBar(f) // Error Incompatible Type
getBar(b) // bar
getFooBar(f) // Error Incompatible Type
getFooBar(b) // foo bar

getFoo(b) functions correctly because Bar necessarily includes all properties of

Foo</code. On the other hand, both <code>getBar(f)

and getFooBar(f) fail due to the absence of the key bar in the Foo type.

If we redefine Bar as follows:

export interface Bar extends Foo {bar? : string}

The compiler acknowledges that Foo meets the minimum requirements for the Bar type. However, it is important to account for potential null values. As a result, the following adjustment enables successful execution:

getBar(f)

Nevertheless, the presence of implicit nulls prompts the compiler to issue warnings. This necessitates modifying the function accordingly:

function getBar(b : Bar) {
    let bar = b.bar
    if(bar === undefined) bar = b.foo;
    console.log(bar);
}

getBar(b) // bar
getBar(f) // foo

Enhancing the theme using material-ui@next and typescript

Answer №1

Answer №2

Similar questions

Is it possible for Angular.js to interact with JSTL expression language?

Is it considered good practice to make a POST request within a GET request?

What is the best way to construct an AJAX call that includes two sets of POST data?

Steps to display API data as HTML in a React app instead of a string when passed as a prop

Deactivate a setInterval function within a Vue.js component

Tips for inserting a value into a specific location within an array using JavaScript

Is it possible to achieve a fade effect in material-ui that truly hides the component instead of just disabling its visibility? If so, how can this be accomplished?

Performing a Search Operation using AJAX with Elasticsearch

displaying HTML on the web page only, without appearing in the text input field

When the condition fails to activate

When I click the back button on my mouse in React, it returns JSON data instead of HTML and CSS

Error: The initial parameter must be a string, Buffer, ArrayBuffer, Array, or Array-like Object. An object type was passed in instead in CryptoJS

Unexpected TypeError thrown by a simple react-cube-navigation demonstration

Ways to expedite the process of retrieving data for a JavaScript array

Is it possible to synchronize Vue data values with global store state values?

Delay the loading of HTML elements to improve website performance

A More Straightforward Approach to Unsubscribing from Observables in Angular 7

Issue with Angular routing not functioning properly post form submission

Having a single quote within a double quote can cause issues with JavaScript code

Retrieving Array keys from PHP using jQuery