{"id":6247,"date":"2022-12-05T05:05:45","date_gmt":"2022-12-05T05:05:45","guid":{"rendered":"https:\/\/studysection.com\/blog\/?p=6247"},"modified":"2022-12-05T05:35:49","modified_gmt":"2022-12-05T05:35:49","slug":"react-reactjs-module-design-pattern","status":"publish","type":"post","link":"https:\/\/studysection.com\/blog\/react-reactjs-module-design-pattern\/","title":{"rendered":"React \/ ReactJS – Module Design Pattern"},"content":{"rendered":"

React is likely the most well-liked JavaScript library for creating user interfaces, in part because of its impartiality. No matter if you choose to view React<\/a> as a framework or library, one thing that can be agreed upon is its hands-off approach to how developers should construct React applications, which provides developers and developer teams the freedom to determine how they want their applications to be made. After working on many React projects with various teams and researching previously created React applications, you identify some common design patterns.
\nIn this article, we’ll be looking at three popular design patterns for building React applications.<\/p>\n

    \n
  1. \n

    Presentational and Container Component Pattern<\/h2>\n

    This is a pattern coined by Dan Abramov. during this pattern, components are divided into:
    \nPresentation Components:<\/strong> These are components that are liable for how the UI looks. They don\u2019t have any dependencies on any part of the application and are used to display data. An example may be a list:
    \nconst ItemsList = (props) => {
    \nreturn (
    \n<ul>
    \n{props.items.map((item) => (
    \n<li key={item.id}>
    \n<a href={item.url}>{item.name}<\/a>
    \n<\/li>
    \n))}
    \n<\/ul>
    \n);
    \n};<\/code>
    \nIn the example above, our ItemsList component is merely responsible for displaying the data passed as props on the user interface. Presentational components are also called stateless. functional components but can also be written as class components and can contain state that relates to the UI.
    \nclass TextInput extends React.Component {
    \nconstructor(props) {
    \nsuper(props);
    \nthis.state = {
    \nvalue: \"\"
    \n};
    \n}
    \nrender() {
    \nreturn (
    \n<input value={this.state.value}onChange={(event) => this.setState({ value: event.target.value })}\/>
    \n);
    \n}
    \n}<\/code>
    \nIn the example above, we\u2019ve created a presentational class component, TextInput, liable for managing its state.
    \nContainer Components:<\/strong> Unlike presentational components, container components are skilled in how things work. They’re usually class components that contain lifecycle methods and presentational components. It’s also where data fetching happens.
    \nclass TvShowsContainer extends React.Component {
    \nconstructor(props) {
    \nsuper(props);
    \nthis.state = {
    \nshows: [],
    \nloading: false,
    \nerror: \"\"
    \n};
    \n}
    \ncomponentDidMount() {
    \nthis.setState({ loading: true, error: \"\" });
    \nfetch(\"https:\/\/api.tvmaze.com\/schedule\/web?date=2020-05-29\")
    \n.then((res) => res.json())
    \n.then((data) => this.setState({ loading: false, shows: data }))
    \n.catch((error) =>
    \nthis.setState({ loading: false, error: error.message || error })
    \n);
    \n}
    \nrender() {
    \nconst { loading, error, shows } = this.state;
    \nreturn (
    \n<div>
    \n<h1> Tv Shows <\/h1>
    \n{loading && <p>Loading...<\/p>}
    \n{!loading && shows && <ItemsList items={shows} \/>}
    \n{!loading && error && <p>{error}<\/p>}
    \n<\/div>
    \n);
    \n}
    \n}<\/code>
    \nWe\u2019ve created a TVShowsContainer component that fetches data from an API when the component mounts within the example above. Additionally, it sends that information to the ItemsList presentational component that we earlier created. The separation of concerns and component reuse are advantages of this pattern. Other container components can reuse the ItemList presentational component to display data since it doesn\u2019t tightly include the TvShowsListContainer. You’ll view the working application here.
    \nDo note that Dan also mentions that he\u2019s not promoting this pattern as he\u2019s changed his view on the matter since he originally coined it. However, you would possibly find it useful for your particular use case which is why I thought it relevant to be mentioned on this list.<\/li>\n

  2. \n

    Provider Pattern<\/h3>\n

    Prop drilling is a huge issue for React developers. Prop drilling may be a scenario in which data (props) is passed down to different components until it gets to the component where the prop is needed. While prop-drilling isn\u2019t bad, it becomes an issue when unrelated components share data, which brings us to the Provider pattern. The Provider pattern allows us to store data in a central location, e.g., the React Context object, and therefore the Redux store. Any component that requires this information can then receive it directly from the Context Provider\/Store without probing any props.
    \nImagine implementing dark mode for an internet app and making unrelated components respond to a theme change triggered by a different component. We will achieve that using the Provider pattern. We create a React context object for storing the worth of the theme.
    \nimport { createContext } from \"react\";
    \nconst ThemeContext = createContext({
    \ntheme: \"light\",
    \nsetTheme: () => {}
    \n});
    \nexport default ThemeContext;<\/code><\/p>\n

    In the App.js file, we wrap imported components with ThemeContext.Provider. This gives the different components, and their children access to the Context object created<\/em><\/p>\n

    import React, { useState, useMemo } from “react”;
    \nimport Header from “.\/Header”;
    \nimport Main from “.\/Main”;
    \nimport ThemeContext from “.\/context”;
    \nimport “.\/styles.css”;
    \nexport default function App() {
    \nconst [theme, setTheme] = useState(“”);
    \nconst value = useMemo(() => ({ theme, setTheme }), [theme]);
    \nreturn (
    \n<ThemeContext.Provider value={value}>
    \n<div className=”container”>
    \n<Header \/>
    \n<Main \/>
    \n<\/div>
    \n<\/ThemeContext.Provider>
    \n);
    \n}
    \nThemeContexts cannot be modified by default because they are stateless. To unravel this, we will connect the ThemeContext to a state and provide an update function in the ThemeContext to modify the state.
    \nTo access ThemeContext within the components, we will make use of the useContext hook introduced in React 16.9.
    \nimport { useContext } from \"react\";
    \nimport ThemeContext from \".\/context\";
    \nconst Header = () => {
    \nconst { theme, setTheme } = useContext(ThemeContext);
    \nconst toggleTheme = () => {
    \nif (theme === \"dark\") {
    \nsetTheme(\"\");
    \nreturn;
    \n}
    \nsetTheme(\"dark\");
    \nreturn;
    \n};
    \nreturn (
    \n<header className={theme === \"dark\" && \"dark\"}>
    \n<h1> Tv Shows <\/h1>
    \n<button onClick={toggleTheme}>Toggle Theme<\/button>
    \n<\/header>
    \n);
    \n};
    \nexport default Header;
    \nimport { useContext } from \"react\";
    \nimport ThemeContext from \".\/context\";
    \nconst Main = () => {
    \nconst { theme } = useContext(ThemeContext);
    \nreturn (
    \n<main className={theme === \"dark\" && \"dark\"}>
    \n<h2>{\" \"} {theme === \"dark\" ? \"Dark theme enabled\" : \"Light theme enabled\"}<\/h2>
    \n<\/main>
    \n);
    \n};
    \nexport default Main;<\/code>
    \nWhile Context makes it easier to pass data among components, it’s advised to use this approach sparingly because it makes component reuse difficult. You’ll access the working app of the example above here. The Provider pattern is employed in React Router and React-Redux.<\/li>\n

  3. \n

    Compound Components Pattern<\/h3>\n

    Compound components are components that share a state and work together to achieve a common goal. An example is the <select> and <option> HTML elements. When combined, they create a drop-down menu, but they don\u2019t achieve much on their own.<\/p>\n

    The Compound Components pattern is used in popular React UI libraries, e.g. Ant Design and Material UI. Below is an implementation of the Menu component in Material UI
    \nimport * as React from 'react';
    \nimport Menu from '@mui\/material\/Menu';
    \nimport MenuItem from '@mui\/material\/MenuItem';
    \nexport default function MaterialMenu() {
    \nreturn (
    \n<div>
    \n<Button> Menu <\/Button>
    \n<Menu>
    \n<MenuItem>Profile<\/MenuItem>
    \n<MenuItem>My account<\/MenuItem>
    \n<MenuItem>Logout<\/MenuItem>
    \n<\/Menu>
    \n<\/div>
    \n);
    \n}<\/code>
    \nWithout compound components, we’ll have had to pass props to the parent component, then the parent component passes the data down to child components
    \n<Menu items={['Profile','My account', 'Logout']} \/><\/code>
    \nThe above looks simple, but we start having problems passing more props right down to the child component. for instance, imagine we wanted a default selected menu item
    \n<Menu items={['Profile', 'My account', 'Logout']} defaultSelected={1} \/><\/code>
    \nAs more requirements are available, the component starts becoming messy and unusable. A simpler method to do this is by using the compound component pattern.
    \nThere are two ways to create a React component using the compound component pattern approach:<\/p>\n