DEV Community: Anubhav

Publishing your first enterprise-level NPM package

Anubhav — Mon, 25 Sep 2023 19:21:44 +0000

Warning: It's going to be a long read but the effort shall surely be worth the time is something I can guarantee!!

As a developer, contributing to open-source is something everyone obviously wants to do but creating and publishing something of their own to the npm registry is the penultimate challenge any developer wants to overcome.

As such, we shall attempt to do the very same thing over in the following sections and that too in a manner that is not just a beginner approach but a completely professional and an industry-accepted way by which you can publish and document your creations on npm and do an npm i your_package_name anytime and anywhere you want and use it through both the ESM way or the CJS way.

For the sake of an example, we shall attempt to publish a components library to the registry.

We shall be making of the following tools to get our job done:

React: needs no introduction
React Styleguidist: An isolated React component development environment with a living style guide. It takes care of documenting all your components without you having to worry about the UI or linking or any other kind of functionality.
Rollup: Similar to how Webpack or any bundler bundles your code into build files, Rollup compiles small and abstract code pieces into complex bundles served from a single location.
Typescript
Material UI and Emotion

We begin with some configuration files:

a) tsconfig.json

{
    "compilerOptions": {
        "module": "ESNext",
        "allowSyntheticDefaultImports": true,
        "jsx": "react-jsx",
        "lib": ["ESNext", "DOM"],
        "moduleResolution": "Node",
        "declaration": true,
        "esModuleInterop": true,
        "noEmit": false,
        "skipLibCheck": true,
        "strict": true,
        "resolveJsonModule": true,
        "target": "ESNext",
        "inlineSourceMap": true,
        "rootDirs": ["src"],
        "baseUrl": ".",
        "jsxImportSource": "@emotion/react",
        "outDir": "dist",
        "typeRoots": ["node_modules/@types", "@types"]
    }
}

b) tsconfig.esm.json

{
    "extends": "./tsconfig.build.json",
    "compilerOptions": {
      "declaration": false,
      "module": "ESNext",
      "outDir": "dist/esm"
    }
}

c) tsconfig.cjs.json

{
    "extends": "./tsconfig.build.json",
    "compilerOptions": {
      "module": "CommonJS",
      "outDir": "dist"
    }
}

d) tsconfig.build.json

{
    "extends": "./tsconfig.json",
    "compilerOptions": {
      "rootDir": "src"
    },
    "exclude": ["./build/**", "./dist/**", "./jest/**", "**/__tests__/**"]
}

e) styleguide.config.cjs

"use strict";

const path = require("path");
const fs = require("fs");
const TsconfigPathsPlugin = require("tsconfig-paths-webpack-plugin");

module.exports = {
  title: "Title of your components library",
  ignore: ["**/__tests__/**", "**/node_modules/**"],
  exampleMode: "expand",
  defaultExample: true,
  skipComponentsWithoutExample: true,
  styleguideComponents: {
    Wrapper: path.join(__dirname, "./src/theme-provider"),
  },
  pagePerSection: true,
  sections: fs
    .readdirSync("src")
    .filter(
      (path) =>
        fs.lstatSync(`src/${path}`).isDirectory() &&
        !path.startsWith(".") &&
        path !== "__tests__" &&
        fs.existsSync(`src/${path}/README.md`)
    )
    .map((dir) => {
      const name = dir
        .split("-")
        .map((part) => {
          if (part === "cta" || part === "nba") {
            return part.toUpperCase();
          }
          return `${part.charAt(0).toUpperCase()}${part.slice(1)}`;
        })
        .join("");
      return {
        name: name,
        content: `src/${dir}/README.md`,
        components: `src/${dir}/${name}.tsx`,
      };
    }),

  getComponentPathLine: (componentPath) => {
    const componentName = path.basename(componentPath, ".tsx");

    return `import { ${componentName} } from "@your_org/your_package_name";`;
  },

  getExampleFilename: (componentPath) => {
    const specificComponentExampleFile = path
      .join(path.dirname(componentPath), "./README.md")
      .replace();

    if (fs.existsSync(specificComponentExampleFile)) {
      return specificComponentExampleFile;
    }

    const exampleFile = path.join(componentPath, "../../README.md");

    if (fs.existsSync(exampleFile)) {
      return exampleFile;
    }

    return null;
  },

  propsParser: require("react-docgen-typescript").withCustomConfig(
    "./tsconfig.json"
  ).parse,

  webpackConfig: {
    entry: "./src/index.ts",
    module: {
      rules: [
        {
          test: /\.js(x?)$/,
          use: [
            {
              loader: "babel-loader",
              options: {
                presets: [
                  [
                    "@babel/preset-env",
                    {
                      modules: false,
                      targets: {
                        node: "current",
                      },
                    },
                  ],
                  "@babel/preset-react",
                ],
                env: {
                  production: {
                    presets: ["minify"],
                  },
                  test: {
                    presets: ["@babel/preset-env", "@babel/preset-react"],
                  },
                },
              },
            },
          ], // , 'source-map-loader'],
          exclude: /node_modules/,
        },
        {
          test: /\.ts(x?)$/,
          exclude: /node_modules/,
          use: [
            {
              loader: "ts-loader",
              options: {
                transpileOnly: true,
              },
            },
          ],
        },
        {
          test: /\.(woff(2)?|ttf|eot)(\?v=\d+\.\d+\.\d+)?$/,
          exclude: /node_modules/,
          use: [
            {
              loader: "url-loader",
              options: {
                fallback: "file-loader",
                name: "[name].[ext]",
                outputPath: "fonts/",
                limit: 8192,
              },
            },
          ],
        },
        {
          test: /\.(png|jpg|gif)$/i,
          exclude: /node_modules/,
          use: [
            {
              loader: "url-loader",
              options: {
                limit: 8192,
              },
            },
          ],
        },
      ],
    },
    resolve: {
      extensions: [".ts", ".tsx", ".js"],
      plugins: [
        new TsconfigPathsPlugin({
          configFile: "./tsconfig.json",
        }),
      ],
    },
  },
};

Now this is an important file to understand. In simple words, the styleguide config file handles how your guide interprets files and reads/parses them. The above configurations asks you to have an src folder in your root, your theme to be in src/theme-provider, and your entry file to be src/index.ts.
At the same time, it ensures that any and all files in all combinations of README.md within each folder to become the documentation for that component and the root file to be the documentation of your complete project apart from a ton of other configurations.

f) rollup.config.mjs

import commonjs from "@rollup/plugin-commonjs";
import resolve from "@rollup/plugin-node-resolve";
import typescript from "@rollup/plugin-typescript";
import url from "@rollup/plugin-url";
import svgr from "@svgr/rollup";
import peerDepsExternal from "rollup-plugin-peer-deps-external";
import { terser } from "rollup-plugin-terser";

export default [
  {
    input: "src/theme-provider/fonts/index.ts",
    output: [
      {
        file: `dist/theme-provider/fonts/index.js`,
        format: "cjs",
        sourcemap: true,
      },
      {
        file: `dist/esm/theme-provider/fonts/index.js`,
        format: "esm",
        sourcemap: true,
      },
    ],
    external: ["tslib"],
    plugins: [
      peerDepsExternal(),
      resolve(),
      commonjs(),
      typescript({ tsconfig: "./tsconfig.build.json", declaration: false }),
      svgr(),
      url({
        include: ["**/*.woff2"],
        // setting infinite limit will ensure that the files
        // are always bundled with the code, not copied to /dist
        limit: Infinity,
      }),
      terser(),
    ],
  },
];

As the name goes, this obviously becomes the config for rollup that we shall be using.

g) package.json

{
  "name": "@your_org/your_package_name",
  "version": "1.0.0",
  "main": "dist/index.js",
  "src": "src/index.ts",
  "module": "dist/esm/index.js",
  "types": "dist/index.d.ts",
  "scripts": {
    "compile": "tsc",
    "build": "tsc -p tsconfig.cjs.json && tsc -p tsconfig.esm.json && rollup -c --bundleConfigAsCjs",
    "dev": "styleguidist server --config styleguide.config.cjs",
  },
  "license": "UNLICENSED",
  "files": [
    "dist/",
    "package.json"
  ],
  "typesVersions": {
    "*": {
      "theme-provider": [
        "./dist/theme-provider/index.d.ts"
      ],
      "button": [
        "./dist/button/index.d.ts"
      ],
    }
  },
  "exports": {
    ".": {
      "require": "./dist/index.js",
      "import": "./dist/esm/index.js",
      "types": "./dist/index.d.ts"
    },
    "./theme-provider": {
      "require": "./dist/theme-provider/index.js",
      "import": "./dist/esm/theme-provider/index.js",
      "types": "./dist/theme-provider/index.d.ts"
    },
    "./button": {
      "require": "./dist/button/index.js",
      "import": "./dist/esm/button/index.js",
      "types": "./dist/button/index.d.ts"
    },
  },
  "dependencies": {
    "@emotion/react": "^11.11.1",
    "@emotion/styled": "^11.11.0",
    "@mui/icons-material": "^5.14.0",
    "@mui/lab": "^5.0.0-alpha.136",
    "@mui/material": "^5.14.0",
    "@mui/styles": "^5.14.0",
    "@mui/system": "^5.14.0",
    "classnames": "^2.3.2",
    "react-is": "^18.2.0",
    "react-select": "^5.7.4"
  },
  "devDependencies": {
    "@babel/core": "^7.22.9",
    "@babel/plugin-proposal-private-property-in-object": "^7.21.11",
    "@babel/plugin-transform-runtime": "^7.22.9",
    "@babel/preset-env": "^7.22.9",
    "@babel/preset-react": "^7.22.5",
    "@babel/preset-typescript": "^7.22.5",
    "@rollup/plugin-commonjs": "^25.0.4",
    "@rollup/plugin-node-resolve": "^15.2.1",
    "@rollup/plugin-typescript": "^11.1.3",
    "@rollup/plugin-url": "^8.0.1",
    "@svgr/rollup": "^8.1.0",
    "@types/classnames": "^2.3.1",
    "@types/node": "^20.5.1",
    "@types/react": "^18.2.20",
    "@types/react-dom": "^18.2.7",
    "@types/react-is": "^18.2.1",
    "babel-loader": "^9.1.3",
    "babel-plugin-react-remove-properties": "^0.3.0",
    "babel-preset-minify": "^0.5.2",
    "file-loader": "^6.2.0",
    "react": "^18.2.0",
    "react-docgen-typescript": "^2.2.2",
    "react-dom": "^18.2.0",
    "react-styleguidist": "^13.1.1",
    "rollup": "^3.28.1",
    "rollup-plugin-peer-deps-external": "^2.2.4",
    "rollup-plugin-terser": "^7.0.2",
    "ts-loader": "^9.4.4",
    "tsconfig-paths-webpack-plugin": "^4.1.0",
    "typescript": "^5.1.6",
    "url-loader": "^4.1.1",
    "webpack": "^5.88.1",
    "yalc": "^1.0.0-pre.53"
  },
  "peerDependencies": {
    "@emotion/react": "^11.10.8",
    "@emotion/styled": "^11.10.8",
    "@mui/icons-material": "^5.11.16",
    "@mui/lab": "^5.0.0-alpha.129",
    "@mui/material": "^5.12.3",
    "@mui/styles": "^5.12.3",
    "react": ">=16.8.0",
    "react-dom": ">=16.8.0"
  },
  "sideEffects": false
}

Obviously there's again a ton of things going on here but some of the most important takeaways from this file would be the following entries:

files: These are the files that would actually be shipped away and made available to whoever installs your package.
typesVersions and exports: Post Node 16, TS corrected prioritising typesVersions over exports. As such, the said config ensures that your library works well for any project irrespective of the version of Node being utilised.

With all setups now done, all that needs to be done is create an src folder at the root level and subsequent folders for components within such as:

Don't forget that src/index.ts is our entry file and so whatever we export from individual index.ts files of components has to be imported an subsequently exported from src/index.ts. A little something like:

import Button, {ButtonProps} from './button'

export {Button}
export type {ButtonProps}

We have also configured theme-provider to be used. Would have loved to share snippets for the same here but because it would not be possible, here is a sample for how it would go about.

Now that we are all done, it is FINALLY time to publish our package which is simply a 2-step process:

Build the project using yarn build or npm run build.
Login to your npm account using npm login. This is a one time process and need not be done every time. Make sure you login with the same user specified in the name of your package.json. @your_org in this case.
npm publish --access public

And voila 🎉🎉🎉🎉
Congratulations! Your package is now available on npm. Make sure to change the version number on every subsequent push to the registry.

Congrats and thanks if you made it this far and please feel free to drop any queries or comments that you come across.

The end of an era: CRA thou shalt me be missed

Anubhav — Mon, 10 Apr 2023 13:02:06 +0000

Yes you heard that right! React officially parts ways with the much-coveted, much-used, and much-loved create-react-app.

As a web developer, you can very confidently claim and say that React is probably THE most powerful and versatile frameworks (library :p) available.

And up till now npx create-react-app has certainly been the go-to method/CLI for most of us to bootstrap and kickstart a new React project. However, with the constant evolution and fast-paced changes in the world of technology and development, even a tool such as React needs to keep up the pace just so it does not get left behind; the fist step for which was to ditch CRA and move towards a more robust solution all of which have been documented very eloquently in this doc (oh which reminds me! React FINALLY has a new documentation that moves away from the class-based paradigm and outdated information as compared to the original documentation).

Although a final decision has not been made as to who shall be React's next date to the prom but they do have a bunch of options in consideration which are outlined in this new doc of theirs:

a) NEXT.JS

It's very difficult to see or imagine someone else take away the crown from Next.JS to be React's next partner to the big dance. It's increasing popularity amongst developers plugged in with its advanced features that solve a lot of React's shortcomings definitely make for a good bet for Next to be the next big thing.

With server-side rendering for better performance and user experience to static website generation for better SEO, it's no surprise that React has chosen Next as its first choice for building all sorts of React-based projects using the npx create-next-app CLI for setting up a new project.

b) REMIX

Brought to you by Shopify, Remix although not too well known or used amongst the community, is gaining a lot of traction at a very rapid pace all thanks to its ton of unique features and capabilities.

With SSR capabilities built-in and providing you an option to pick your deployment target, Remix could very well be an integral part of React moving forward.

c) GATSBY

This one is brought to you by the much-loved and free CI/CD tool in the name and shape of Netlify. If you are looking to develop a CMS or want to have built-in and highly extensible GraphQL support, you need not look any further.

With a plethora of simple and easy to hook plugins, Gatsby is making a strong stand for itself in terms of sustenance and shaping how we could perceive or work with React in the near future.

To say that CRA is all but gonna be obsolete or become deprecated would be nothing short than overreacting. For all of its flaws and issues, the simplicity that CRA has offered to the community for so long can hardly ever be replaced. Sure there are a bunch of more performant and optimised solutions, CRA still leaves behind a legacy that would be hard to match!

Setting up ESLINT with TS/JS in your React project in 2023

Anubhav — Mon, 20 Mar 2023 11:01:11 +0000

ESLINT: Does not matter if you are a seasoned or a novice developer, ESLINT is definitely a term you have come across or heard of at the very least. Even I had heard of it a lot and even used it in applications that already had it configured but never had the liberty and or the chance to set it up on my own in a bare project. And that is exactly what we shall be doing today using the following tools:

ESLINT is a pluggable linting tool for JS as well as JSX (basically React) which helps you detect possible errors in your code ranging from a wide array of possibilities such as unused variables in files, illegal comparisons, etc.

PRETTIER is probably the most popular code formatter to enforce a certain and consistent style guide in your codebase.

HUSKY in its own words is a simple tool to improve your commits and more by making use of git hooks.

SETTING UP ESLINT

It's as simple as running the following command in a terminal at the root of your project:

npm init @eslint/config

Once you execute it, you will be prompted with a bunch of questions as follows:-

Based on your requirements and environment, answer the questions accordingly. At least with eslint version 8.0.1, you are only presented with 2 style guides: standard and XO.
Personally, I prefer the standard styling guide but at any give time, it is a personal choice and as such feel free to choose any from a bunch of available options. Once all dependencies are installed, ensure that you have the following packages added as devDependencies to your project:

@typescript-eslint/eslint-plugin
@typescript-eslint/parser
eslint
eslint-config-standard-with-typescript
eslint-plugin-import
eslint-plugin-n
eslint-plugin-promise
eslint-plugin-react

At the time of writing this article, eslint latest version is 8.0.1 and there is a high chance that you may not get @typescript-eslint/parser added directly. If that is the case, do not worry. Just add the same as a dev dependency using

npm i --save-dev @typescript-eslint/parser

Following is a screenshot of the linter configuration that I work with. Feel free to go about the rules section and tweak it as per your flow. However, it is advisable that you do not go about changing the rules cause any style guide is written keeping certain things in mind but like all things, it is your call ultimately.



{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "plugin:react/recommended",
    "standard-with-typescript",
    "plugin:import/typescript",
    "plugin:prettier/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "overrides": [],
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module",
    "project": "./tsconfig.json"
  },
  "plugins": ["react", "prettier"],
  "rules": {
    "@typescript-eslint/triple-slash-reference": "off"
  }
}

NOTE: Do remember to add a .eslintignore file and keep non-essential files such as build, node_modules, dist, etc. in there otherwise the linter will keep yelling at you to fix those changes as well.

SETTING UP PRETTIER

This is comparatively a simple process cause most of the setup for prettier was already taken care of when we set up eslint and the related config file. Hit up the following command:-

npm i --save-dev prettier eslint-config-prettier eslint-plugin-prettier

Add a .prettierrc.js file as follows:



module.exports = {
  arrowParens: "avoid",
  bracketSameLine: true,
  bracketSpacing: false,
  singleQuote: false,
  trailingComma: "all",
  tabWidth: 2,
  useTabs: false,
  semi: true,
  printWidth: 80,
};

NOTE:

Just like a .eslintignore, add a .prettierignore file containing elements that don't need to be checked.
Don't forget to check the format on save setting in VSCode to allow prettier to enforce your changes automatically when you save your code.

SETTING UP HUSKY**

We are almost there. This is probably the trickiest and yet the easiest part of everything. The Husky CLI makes it really easy to set things up. Once again, power up a terminal and run the following command:-
npx husky-init && npm install

This creates a .husky folder at your root level with an existing file called pre-commit and this is the file where you want to add some things so that your codebase is scanned for issues before you are able to commit your code. But before we jump to this file, you wanna edit the scripts part of your package.json by adding the following lines:



"lint": "eslint .",
"lint:fix": "eslint --fix .",
"prettier": "prettier --write .",

Once this is done, you head over to the pre-commit file discussed earlier and add a simple line over there:
npm run lint
which ultimately translates that before you commit your changes, run the lint script as specified in the package.json file.

To be absolutely sure of things, before committing your code, run the following commands in order:
npm run prettier

npm run lint:fix

These will make sure that your code is at least formatted properly and devoid of as many errors that eslint could have fixed automatically for you. If you still see errors on your terminal, head over to the erroneous files and fix the issues manually and then only can you move forward with committing your code.

And that wraps it up. You are all done towards making and keeping your code well maintained. HAPPY HACKING!

M1 and React Native (Not a headache)

Anubhav — Fri, 26 Aug 2022 07:23:00 +0000

For anyone who has worked on or works on React Native, there's no denying that iOS setup, development, and distribution is FAR FAR FAR more difficult than that of Android.
The situation kinda takes a turn for worse with the new CPU architecture, viz. M1 that Apple rolled out a year or two back. There's no denying that M1 is no less than a tech marvel and we don't expect anything less from Apple; but you sure wanna yell out a couple of words out loud to an architecture that just refuses to run a couple of basic commands that used to run as smooth as butter previously.

The most common issue that pops up with this new architecture is the very simple command we execute known as:
pod install

You can expect all pods to be installed without any hiccups but the pods that cause an issue in their installation are:

boost
glog

Let's tackle these issues one by one.

BOOST

Installing pods for boost results in an error similar to =>

In short, the error states that it could not place an authorised request to jfrog.io and is crashing with a 401 unauthorised request. The solution to this couldn't be simpler. Just execute the following command and you're golden:

cd ios && rm -rf Pods && rm -rf Podfile.lock && rm -rf build && pod deintegrate && cd ..

Once you have done this, pod install should move past installation of boost and then hang up on glog.

PS: You might run into many solutions asking you to install the ffi gem and execute a command like
sudo arch -x86_64 gem install ffi

You may give it a whirl but it definitely fails (at least it did for us saying that the architecture specified is invalid) so there's no absolute guarantees that this would most certainly work.

GLOG

Pod installation for glog mostly crashes with an error that looks something like:
error: C compiler cannot create executables.

Once again, the solution is pretty simple. This time instead of one though, we wanna execute 2 commands:

sudo xcode-select --switch /Applications/Xcode.app
cd ios && pod install

Here's one to hoping this article proves helpful for you :D
If you are facing any other issues or if the aforementioned solutions don't seem to pan out for you, feel free to drop the same in the comments down so we may take it forward.

Context + Hooks > React + Redux

Anubhav — Thu, 24 Jun 2021 10:50:43 +0000

Amongst the dev community, one of the most hot and trending technology these days has got to be React and regardless of how you feel about working with it, you have to give it credit for at-least feeling like a full-blown framework despite being a library.
Redux has been the library of choice for global state management for years now but it's high time now that we move forward. The primary reason for this being the verbosity of Redux that not just make it a tad cumbersome to use but also kind of senseless unless you are working on an enterprise-level project.

CONTEXT API

React 16 gave us a wonderful solution to global state management => Context API. A library with syntax very similar to Redux but with exponentially less boilerplate and setup.
Using Context is pretty straightforward. A Provider serves the values:

import React from 'react';
const StateContext = React.createContext(/* default state */);
const App = props => (
  <StateContext.Provider value={{ color: green }}>
    {props.children}
  </StateContext.Provider>
);

And a Consumer uses the values:

const ConsumerComponent = () => (
  <StateContext.Consumer>
    {value => (
      <Button primaryColor={{ value.color }}>Consumer</Button>
    )}
  </StateContext.Consumer>
);

This implementation shall, however, work only for functional components. There are other ways to access context values in class-based components. You may read up on those in the official React docs

...

HOOKS

Soon after the Context API was released in production, hooks were introduced and things were never the same again. It was not just state management that benefited but React in its entirety saw a much-needed overhaul from all the classes that we used to write previously.
Out of the 10 default hooks that React ships with, the useReducer hook can be used to set up Context API within our app. The useReducer hook takes 2 arguments; namely a reducer function and an initial state:

import React, { useReducer } from 'React';

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 };

    default:
      return state;
  }
};

const IncrementComponent = ({ initialCount }) => {
  const [state, dispatch] = useReducer(reducer, { count: 0 });  return (
    <button onClick={() => dispatch({ type: 'increment'})}>
      Increment: {state.count}
    </button>
  );
} ;

This syntax looks awfully similar to Redux. Cool right!
The useReducer hook returns the [state, dispatch] array where state is the current state you can consider dispatch to be like a gun that shoots actions at our data layer. You can call it anything but while looking at a Redux substitute, we can use its naming convention at the very least!
Every time the dispatch method is called, the reducer function is triggered which matches your action type and updates the state as per the payload you send to it.

Now for the fun part!

HOOKS + CONTEXT

Using Context and hooks together allows you to make your own global state management system in hardly 10 lines of code. Intrigued right because that would be pretty neat!

import React , { createContext , useContext , useReducer } from 'react';

export const StateContext = createContext();

export const StateProvider=({ reducer , initialState , children })=>(
    <StateContext.Provider value = {useReducer(reducer,initialState)}>
        {children}
    </StateContext.Provider>
);

export const useStateValue = () => useContext(StateContext)

Et voila. We're done! Let's see what's happening here:

createContext creates a context object and returns it to StateContext which stores the Provider and the Consumer
Next we create StateProvider which is basically a HOC which wraps its children with the values offered by the Provider.
Finally we create useStateValue which is a custom hook which uses the StateContext context. We did this because otherwise you would have to import useContext and StateContext in all places wherever you wanted access to these values. Building up on the DRY principle of coding, we created a universal hook to take care of the same once and for all.

...
Next we just need a reducer and an initial state to start using the StateProvider component. We already took a look at what a reducer could look like earlier. The initial state can be anything you want; a JSON object, an array, or whatever fits your purposes the best.

Now let's see how to use the StateProvider component and we're all set. In our entry file (generally App.js), we just need to wrap our return block with the StateProvider =>

import { StateProvider } from './utils/StateProvider';
import reducer, { initialState } from './utils/reducer';

const App = () => {
  return (
    <StateProvider initialState={initialState} reducer={reducer}>
        // Content ...
    </StateProvider>
  );
}

SIDE NOTE

To now access the state values inside your component, you simply go like:

import { useStateValue } from '../utils/StateProvider'

const MyComponent = () => {
    const [state, dispatch] = useStateValue()
}

You can always use object destructing to just get the required slices of data from your global state instead of getting the entire state.

This implementation is viable only for functional components because useStateValue under the hood use the useContext hook and the rules of hooks clearly state that hooks can only be called inside the body of a functional component. If you want to use these values in a class-based component, you shall have to go over the bit more verbose method of using Consumer or contextType but in modern times, working with functional components is the norm and there's no way that this implementation shall break any time in the future.