material-ui VS styled-components

import * as React from 'react'; import Document, { Html, Head, Main, NextScript } from 'next/document'; import createEmotionServer from '@emotion/server/create-instance'; import theme from '../styles/theme'; import createEmotionCache from '../lib/createEmotionCache'; export default class MyDocument extends Document { render() { return ( {/* PWA primary color */} ); } } // `getInitialProps` belongs to `_document` (instead of `_app`), // it's compatible with static-site generation (SSG). MyDocument.getInitialProps = async (ctx) => { // Resolution order // // On the server: // 1. app.getInitialProps // 2. page.getInitialProps // 3. document.getInitialProps // 4. app.render // 5. page.render // 6. document.render // // On the server with error: // 1. document.getInitialProps // 2. app.render // 3. page.render // 4. document.render // // On the client // 1. app.getInitialProps // 2. page.getInitialProps // 3. app.render // 4. page.render const { renderPage: originalRenderPage } = ctx; // You can consider sharing the same emotion cache between all the SSR requests to speed up performance. // However, be aware that it can have global side effects. const cache = createEmotionCache(); const { extractCriticalToChunks } = createEmotionServer(cache); ctx.renderPage = () => originalRenderPage({ // eslint-disable-next-line react/display-name enhanceApp: (App: any) => (props) => , }); const initialProps = await Document.getInitialProps(ctx); // This is important. It prevents emotion to render invalid HTML. // See https://github.com/mui-org/material-ui/issues/26561#issuecomment-855286153 const emotionStyles = extractCriticalToChunks(initialProps.html); const emotionStyleTags = emotionStyles.styles.map((style) => ( )); return { ...initialProps, // Styles fragment is rendered after the app and page rendering finish. styles: [ ...React.Children.toArray(initialProps.styles), ...emotionStyleTags, ], }; };

Enter fullscreen mode Exit fullscreen mode

step 7
we also need to wrap material UI with the app component, let copy the following lines of code to _app.ts file inside the page folder.

import * as React from 'react';
import Head from 'next/head';
import { AppProps } from 'next/app';
import { ThemeProvider } from '@mui/material/styles';
import CssBaseline from '@mui/material/CssBaseline';
import { CacheProvider, EmotionCache } from '@emotion/react';
import theme from '../styles/theme';
import createEmotionCache from '../../src/lib/createEmotionCache';

// Client-side cache, shared for the whole session of the user in the browser.
const clientSideEmotionCache = createEmotionCache();

interface MyAppProps extends AppProps {
  emotionCache?: EmotionCache;
}

const App = (props: MyAppProps) => {
  const { Component, emotionCache = clientSideEmotionCache, pageProps } = props;
  return (
    
      
        My page
        
      
      
        {/* CssBaseline kickstart an elegant, consistent, and simple baseline to build upon. */}
        
        
      
    
  );
};

export default App;

Enter fullscreen mode Exit fullscreen mode

Material-UI - 74K⭐

For some reason, you don't want to write in TS, and only in plain JS, but you want your project to have types available for other people who use Typescript. e.g. as it is done by mui project

I've tried using Next.js v11 and 12. I'm using a custom _app.js and _document.js as specified HERE. I'm confused to why it'd work locally but not on Vercel. Does anyone have any thoughts?

With over 73, 000 plus stars on GitHub, Material UI is one of the most popular UI component libraries which is based on the Google Material's Design. It comes with accessible and easily customizable components that can be used in your React projects. In addition, this open-source library has very detailed documentation to help navigate through the implementation of its features.

import * as React from 'react'; import Document, { Html, Head, Main, NextScript } from 'next/document'; import createEmotionServer from '@emotion/server/create-instance'; import createEmotionCache from '../utility/createEmotionCache'; export default class MyDocument extends Document { render() { return ( ); } } // `getInitialProps` belongs to `_document` (instead of `_app`), // it's compatible with static-site generation (SSG). MyDocument.getInitialProps = async (ctx) => { // Resolution order // // On the server: // 1. app.getInitialProps // 2. page.getInitialProps // 3. document.getInitialProps // 4. app.render // 5. page.render // 6. document.render // // On the server with error: // 1. document.getInitialProps // 2. app.render // 3. page.render // 4. document.render // // On the client // 1. app.getInitialProps // 2. page.getInitialProps // 3. app.render // 4. page.render const originalRenderPage = ctx.renderPage; // You can consider sharing the same emotion cache between all the SSR requests to speed up performance. // However, be aware that it can have global side effects. const cache = createEmotionCache(); const { extractCriticalToChunks } = createEmotionServer(cache); /* eslint-disable */ ctx.renderPage = () => originalRenderPage({ enhanceApp: (App) => function EnhanceApp(props) { return ; }, }); /* eslint-enable */ const initialProps = await Document.getInitialProps(ctx); // This is important. It prevents emotion to render invalid HTML. // See https://github.com/mui-org/material-ui/issues/26561#issuecomment-855286153 const emotionStyles = extractCriticalToChunks(initialProps.html); const emotionStyleTags = emotionStyles.styles.map((style) => ( )); return { ...initialProps, // Styles fragment is rendered after the app and page rendering finish. styles: [ ...React.Children.toArray(initialProps.styles), ...emotionStyleTags, ], }; };

One of the benefits of using Material UI icons other than the fact that it’s huge with multiple variants is that it is supported by all major platforms, as well as browsers and if you ever get stuck you can definitely check out their GitHub repo. If that’s not enough, they have an entire page dedicated to support.

The one on the official MUI's Github repo featuring Next.js with TypeScript (my framework of choice) didn't follow standard Next.js folder structure.

As already mentioned in the previous section, a certain flavor of functional programming can be quite elegant in JavaScript. The simplicity of the object model makes it very convenient to organize and operate on data. Dynamic typing and type coercion allows you to take certain shortcuts (unless you are trying to sort a list of numbers...). Use the strengths of whatever language you are using to your advantage. It is good to push the boundaries of the language to create new things. For example, styled components and GraphQL have normalized the use of tagged template literals for domain specific languages (DSLs). But in general, you'll have a much better time working with the grain of the language than against it.

I want to be clear that I am far from a TailwindCSS hater. I think the framework is awesome and I am looking forward to its future in the space. I definitely feel like I need more time with it and more experience working with it, but right now I'm more excited about Styled Components (which I've taken a love to from Josh W. Comeau's CSS for JavaScript Developers Course) and also Vanilla Extract which I plan to look into more for future projects. With other tools like Chakra UI also looming over my shoulder competing for my headspace with styling, these small frustrations from Tailwind keep adding up and I'm not sure if I'll be using it for my own personal projects anymore.

You could checkout styled-components which allows you to make components and add css to them in javascript. With this, you can create variants, and wherever you need a specific variant, just create a prop called variant, and pass in which specific style of component you need. Note you do need the babel-plugin-styled-components for it to work in nextjs

Yo it dis style components (and they rock)

Let's face the fact that this calculation is not straightforward and hard to read, even when you are familiar with the technique. Luckily for us, we can extract SASS mixins, or utility functions for various CSS-in-JS libraries (like styled-components).

styled-components for styling needs

This article aims to explain how we could use react-hot-toast and styled-components to create some beautiful-looking toast messages 😉

No, you're right about using @use and @forward rather than @import. These days I generally work with CSS in JS using something like styled-components, but when I do work on static sites, I funnily enough do use a rather nice gulp build I've put together over the years, that leverages browserstack and pug, so @import works for me... but I should really update my boilerplate.