I do prefer with showing an example that you can find in this codesandbox

For example, in the code sandbox linked above, in the above situation all does work, and paragraph change cause console only when the button that listen to click is indeed clicked

But in App.js if you comment out <AppContainerWithContext /> and load <AppContainer />, there are two states managed in the container, one called titleText and the other called paragraphText. titleText is passed as a prop to component called TitleText and paragraphText is passed to a component called ParagraphText. Both components are wrapped in React.memo(). There are two buttons called in the AppContainer and each has a function that changes the text back and forth based on the value of separate boolean states.

This happens when a state changes in context, every app (component) accessing data from that context re-renders, even if it's not utilizing the state data that changed (because it's all ultimately passed through the value object). React.Memo does not work on values accessed from context the same way it does for properties.

The Problem: Why Does useContext Trigger Unnecessary Re-Renders?

React's useContext hook allows components to access shared state from a context provider. However, every time the context value changes, all components consuming the context re-render, even if the part of the context they rely on hasn't changed. This can lead to significant performance issues in large applications.

Example of the Issue:

Consider the following context and components:

const AppContext = createContext();

export function AppProvider({ children }) {
  const [title, setTitle] = useState("Title A");
  const [paragraph, setParagraph] = useState("Paragraph A");

  const value = { title, setTitle, paragraph, setParagraph };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

export function useAppContext() {
  return useContext(AppContext);
}

Now, suppose you have two components, as in teh codesandbox before, TitleText and ParagraphText, each consuming a specific part of the context:

const TitleText = () => {
  const { title } = useAppContext();
  return <h1>{title}</h1>;
};

const ParagraphText = () => {
  const { paragraph } = useAppContext();
  return <p>{paragraph}</p>;
};

When setTitle is called, both TitleText and ParagraphText will re-render because the entire context value object changes, even though only the title has been updated.

Common Solutions and Their Downsides

One solution is indeed as illustrated with the initial code in the sandbox.

1. Using React.memo

Wrapping components with React.memo can prevent unnecessary re-renders if the component’s props haven’t changed:

export default React.memo(TitleText);

But this approach present 2 main downsides.

Downsides:

• Dependency Management: Ensuring props or context values passed to components are stable (e.g., wrapped with useCallback or useMemo) can quickly become cumbersome.

• Inefficient for Large State: For complex applications, it doesn’t scale well because every component still subscribes to the entire context.

Another approach is create a Context for each “main” state that is shared among component that need those state changes and based on those state change need to re-render.

This is called “Splitting Contexts” like:

const AllContextProvider = props => {
  return (
    <UserProvider>
      <ThemeProvider>
        <NotifProvider>
          <TimelineProvider>
            <CertProvider>
              <MenusProvider>
              {props.children}
              </MenusProvider>
            </CertProvider>
          </TimelineProvider>
        </NotifProvider>
      </ThemeProvider>
    </UserProvider>
  );
};

and the using as:

…

const TitleContext = createContext();

const ParagraphContext = createContext();

…

But this approach though is completely fine present some issue:

2. Splitting Contexts

Downsides:

• Leads to "Provider Hell" where components are wrapped in multiple providers.

• Harder to manage and scale with more state variables.

A Scalable Solution: Refactoring to useReducer

So a better approach is to refactoring from the initial createContext setup using useState to a useReducer-based implementation provides a scalable and efficient solution I have wrote in this codesandbox.

This was considering the initial use of useState

Initial Implementation with useState

import React, { createContext, useContext, useState } from "react";

const AppContext = createContext();

export function AppProvider({ children }) { const [title, setTitle] = useState("Title A"); const [paragraph, setParagraph] = useState("Paragraph A");

const value = { title, setTitle, paragraph, setParagraph };

return <AppContext.Provider value={value}>{children}</AppContext.Provider>; }

export function useAppContext() { return useContext(AppContext); }

While functional, this implementation suffers from re-render issues because setTitle and setParagraph cause the entire value object to change, leading to re-renders of all consuming components.

Refactored Implementation with useReducer

Using useReducer allows us to centralize state management and define explicit actions for state updates, reducing unnecessary re-renders. Here’s the refactored version:

import React, { createContext, useContext, useReducer, useCallback } from "react";

// Initial state
const initialState = {
  title: "Title A",
  paragraph: "Paragraph A",
};

// Reducer function to handle state updates
const reducer = (state, action) => {
  switch (action.type) {
    case "SET_TITLE":
      return { ...state, title: action.payload };
    case "SET_PARAGRAPH":
      return { ...state, paragraph: action.payload };
    default:
      return state;
  }
};

// Create the context
const AppContext = createContext();

// Custom hook for consuming context with a selector
export function useAppContext(selector) {
  const { state } = useContext(AppContext);
  return selector ? selector(state) : state;
}

// Context provider
export function AppContextProvider({ children }) {
  const [state, dispatch] = useReducer(reducer, initialState);

  const setTitle = useCallback((title) => {
    dispatch({ type: "SET_TITLE", payload: title });
  }, []);

  const setParagraph = useCallback((paragraph) => {
    dispatch({ type: "SET_PARAGRAPH", payload: paragraph });
  }, []);

  const value = {
    state,
    setTitle,
    setParagraph,
  };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

Selective Subscriptions in Components

With useReducer, we can now implement selective subscriptions to ensure only the relevant parts of the state trigger re-renders:

TitleText Component

import React from "react";
import { useAppContext } from "../contexts/AppContext";

const TitleText = () => {
  console.log("TitleText Triggered");

  // Subscribe to the title part of the state
  const title = useAppContext((state) => state.title);

  return <h1>{title}</h1>;
};

export default React.memo(TitleText);

ParagraphText Component

import React from "react";
import { useAppContext } from "../contexts/AppContext";

const ParagraphText = () => {
  console.log("ParagraphText Triggered");

  // Subscribe to the paragraph part of the state
  const paragraph = useAppContext((state) => state.paragraph);

  return <p>{paragraph}</p>;
};

export default React.memo(ParagraphText);

This ensures TitleText re-renders only when the title changes, and ParagraphText re-renders only when the paragraph changes

Why This Works

1. Centralized State Management:

   • The reducer handles all state updates in one place.

2. Selective Subscriptions:

   • Components only subscribe to the parts of the state they need, avoiding unnecessary re-renders.

3. Scalability:

   • Adding new state variables or actions is straightforward.

4. Performance Optimization:

   • This pattern minimizes re-renders while maintaining simplicity and readability.

Lessons from Redux and Meta

This approach aligns with patterns established by Redux, which uses reducers and subscribable stores for efficient state management. React’s useReducer brings these concepts into its core API, offering a lightweight and performant solution without needing external libraries.

Conclusion

When using useContext, unnecessary re-renders can be a significant challenge. While React.memo and splitting contexts offer partial solutions, adopting useReducer with selective subscriptions provides a scalable, maintainable, and efficient approach. This pattern combines the best of React’s core features with lessons learned from libraries like Met's Flux and Redux, making it ideal for managing global state in modern applications.

I have to be honest in the past something like 8 years ago I have spend some amount of time thinking when was the right to commit. Then as for any topic I read around and different source, and as everything this depends of the project, like a solo one, or with a Team. Indeed for this different cases, I have 2 different approach, both based on the principle to see who is going to review the commits: in the first case me of a version of me in the future or eventually another component of the Team in the future.

But then a connection of mine wrote me:

"At the moment I'm spending more time planning out a commit than actually writing code when adding a new feature. Less than two hours would be lucky, some times I'd spend a good part of the day without writing any code. This is making me unhappy, since I don't feel I'm productive enough (I'm living with my parents, and have never been employed as a programmer)"

If I don't do this amount of planning, I just end up writing code that will have to be undone before I commit, and this just messes up my project, because don't like wasting any code I've already written and try to recycle it as much as possible (my precious).

Someone said that programming isn't about how fast you can type, it's about how fast you can think. I'm not very good at thinking fast." ( Well I am the same).

I think I'm overly cautious making my productivity not economically viable, but even still its far too easy for me to waste a whole lot of time making a mess of my codebase."

This was what he told me and I though that at his stage I even didn't had much thoughts but at lower level.

My experience is that when coding for a living, especially as a junior in a team, typically not much design work is needed. This is because you'll be working in an existing code base. Chances are, you'll often be working on a feature that is similar to existing features, so you can look at those as an example. This is nowhere near as boring as it may sound; one can is learning plenty of things, still need to understand the examples and adapt them to suit your needs.

Designing something new can indeed be much harder, but it is also much rarer, especially when you're a junior developer, or let's say when you take the challenge to develop something on the side even adapting tutorials can be.

That is to say: in a typical junior-level development job, I don't think one run into the things this person was worried about. Or at least to a far smaller extent.

Planning and coding are very much iterative processes. You plan a bit, try to create some code with the planning in mind, which makes you realize that you overlooked something during planning, so you adjust the plan, code some more, rinse, repeat.

I like to think that this is also how artists work. It's a creative journey. Often messy, sometimes boring, sometimes exhilarating, sometimes frustrating. Sometimes you end up with something boring that just works, sometimes with something beautiful that doesn't work. And, every now and then, with something that works and is beautifully elegant.

""Someone said that programming isn't about how fast you can type, it's about how fast you can think. I'm not very good at thinking fast.""

Actually neither are most people, especially if they have to do the thinking without seeing any code. Coding helps to make things concrete. It may also obfuscate the bigger picture, so zooming in (code) and out (planning) is part of the iterative process.

It's also worth noting that people, after years of professional experience, develop a kind of muscle memory for specific approaches, and an instinct for applying these. Which is half the battle when making something new. You cannot be expected to have that already (nor should you expect it from yourself).

Unfortunately the "internet" show only ready "work" as YouTubers if they would make up stuff on the spot, type it in and are done. That is not how it goes.

They planned and practiced too beforehand or they show you things they have done hundreds of times before, that are in their routine.

When you see a musician play for one minute on YouTube it is safe to assume they spent days practicing, recorded tens of takes and ultimately picked the best one. And that is not counting the years they put in to get up to their level in the first place.

Writing software is a skill like any other that takes time to develop. And different people specialize in different things. And, in your particular specialty, there will likely always be some people who can do things quicker. If you are just starting with Git, I would recommend this free resource live project from manning Getting Started with Git or / after to get even more practice for advance topic and work in a Team and feel completely confident, I would recommend this other book Git in practice Deciding when and where to optimize is another thing. It seems many people tend to be obsessively working to satisfy own compulsive need to eradicate any imperfections. This is fine in the environment how many great creators started their career. The key but not easy to put in practice is to enjoy it and learn from it while no one is asking you when it's done yet.

My general approach is that code that just works (and is readable) and that apply to code style if one is working in a Team, is good enough.

If later on, new requirements or new features means that the code is no longer good enough, you can adjust it. That adjustability is the reason the world moved away from specialized hardware and embraced software (running on generic hardware).

My approach with unfinished "Classes" or "Component" that for example still miss the part for retrieve API or that "useEffect" to implement something that has to run only after first render or after a variable change, is to "stash", so I can recall that method / approach or part, where I put some effort but on overall still not working or not working as should or as I expect, anytime I need or integrate with a branch or another approach.

Indeed I see commits are not something you plan. Commits, especially in the early stages of figuring out a problem, are little more than save-points along a journey. Instead, spend time thinking about the problem.

Break big problems into little problems, and then break those down into smaller problems. This is one of the first rule and approach are taught at university or bootcamps, or at least it should be. At least it was at University of Bologna during my Java course.

Keep decomposing and digesting problems until your mind can see a single line of code.

Write that line of code. Keep writing code as you think. Mess up. Change the code. Change it 15 more times(stash it if some part works as your expected), if need be. Stop and commit when you feel like losing that code would be a big setback, or during a natural break in your rhythm of thought and writing code.

There is no general rule or guideline. When to commit is more a feeling than some methodological practice. Basically, if you think, "it would really suck to lose this code while I figure things out," then commit what you have. Just be sure to work in your own branch so no one else has to deal with whatever state your code is in.

Don't worry about whether the code works, compiles, or looks pretty. Many version control systems allow you to combine many messy commits into one clean, cohesive changeset.

Version control is a tool just as much as a text editor. Version control just happens to be really good at backing up your work.

So in general there should not really time planning a commit.

The approach should be to write code until you feel like you have something to lose, then commit those changes so you don't.

This topic is connect on the question of how many commits to do and also has to do with the great tooling and feature that git give to developers, and that is amazing tooling set.

Well let's keep it simple and assume that those data once retrieve are going to be used in few places so a useState() or few of them will be enough, so in following example is not used any Redux or other global state management.

So we would like to re-render our component once the asynchronous call is over.

Many would think about memoisation and so use useMemo() but unfortunately this would not be the best approach, actually even a bad one as even in React specifically mentions that useMemo should not be used to manage side effects like asynchronous API calls.

This is because triggering an async call is a side effect, so it should not be performed during the render phase - neither inside the main body of the component function, nor inside useMemo(...) which also happens during the render phase. Instead all side effects should be triggered inside useEffect.

We should instead you should use React's state that keeps the value of async calls returned and allow to trigger a re-render.

But there are some little adjustment that will even improve such approach, let's write some code and I will explain :

const [result, setResult] = useState()

useEffect(() => {
  let active = true
  load()
  return () => { active = false }

  async function load() {
    setResult(undefined) // this is optional
    const res = await someLongRunningApi(arg1, arg2)
    if (!active) { return }
    setResult(res)
  }
}, [arg1, arg2])

Here we call the async function inside useEffect.

Note that you cannot make the whole callback inside useEffect async( otherwise it will create a loop) - that's why instead we declare an async function load inside and call it without awaiting.

The effect will re-run once one of the args changes - this is what is needed in most cases.

So we can make sure to memoise args if in need to re-calculate them on render.

Doing setResult(undefined) is optional - and let in this way have fresh data at each render but one could simply need to keep the previous result on the screen until the next result is availabe. Or one might do something like setLoading(true) so the user knows what's going on.

Using active flag is important. Without it we are exposing ourself to a **race condition **waiting to happen: the second async function call may finish before the first one finishes:

Those are what then will happens in a race condition:

start first call

start second call

second call finishes, setResult() happens

first call finishes, setResult() happens again, overwriting the correct result with a stale one

Our component ends up in an* inconsistent state*. We avoid that by using useEffect's cleanup function to reset the active flag:

set active#1 = true, start first call

arg changes, cleanup function is called, set active#1 = false

set active#2 = true, start second call

second call finishes, *setResult() *happens

first call finishes, *setResult() *doesn't happen since active#1 is false

This is one of the use case in which useEffect + useState( or in case of large application, a global state management) this useEffect is the best approach and actually the one to go for deal with side effects such APIs calls.

There are times indeed when one is forced to use a computer in which one has not admin privilege or even having those, there is not time to set or configure an entire Development Enviroment such an IDE, configured with all plugins, libraries etc. It could be also useful when is not advisable to run code locally because either the hardware is not enough for the task done by the code base, or because we are to a client doing other projects and we want separate things but as set a virtual Machine or a Docker container is not worth the time.

Nevertheless software development never stop or sleep as can be done anytime and in any location especially nowadays with the "Cloud".

So this post is the first of a series on remote tools and solution and how to set them.

Nervertheless this first, will cover basic steos on how connect a local computer with Windows 10 for which we have only a simple User but could be applied to any OS.

It meant that we can still install software under that user account and have enough space for do it.

The following of this will cover the amazing possibilities offered by Visual Studio Online and further I wil test and write about the Visual Studio Remote Development .

Let's start, first install we have to install Visual Studio Code for Windows and MINGW64 that is the bash tool for Git on Windows and that use bash sintax.

Create an Azure account if you want use Visual Studio either locally or the Online version or later the Visual Studio Remote Development.

Once we have those, we need to decide with protocol to use, either SSH or HTTP(S), in order to connect, o our repositories(any). Its said that these steps can be done in some Companies by the DevOps/ SRE Team but as a developer you maybe need to be "adpating" be a good learning process and also is about a specific Repository and as a special case where reach out those team won't be effient or in case they are busy.

I write in advance that the connection via tunneling is subject to IT approval and I went only for it in order to explor the possibilities in order to have a clear and reproducible steps in case needed and the tunnelling connection is allowed by IT policies.

In general the SSH is a better way for the developer, as once setted it up will not require to provide in the future Git Remote operation ( pull, push, ect) credentials.

Instead the HTTP way do not require any approval as long as one has access to internet with the user because the protocol it use is already trackable by default by the IT enterprise. Also for out goal to work to some code from anyway, will suffice.

First step is to clone the Github repository (but this apply to any Git remote provider, so also Gitlab e.g), usually via http is something like :

 git clone https://github.com/User/YourRepo.git

Then you run the command, but unfortunately you get something like :

This is highly happening because you are working behind an Enterpise proxy firewall.

To overcome it, and as we use HTTP protocol basically we need to tell Git how to use the same configuration that our browser use in order to let us reach outside websites.

You need to find your Proxy Server Name, usually this is under a file with the extention of .pac sometimes this easly to find from the broswer.

For example in Chrome it is under Settings, then "Open Proxy Settings"( I have a German Computer and Account, but that is basically the translation), it will open a System Window where it show where the Proxy Script is.

I have of course removed mine for privacy reasons, but is under Script Address

This file can be open with any editor, Notepad or Notepad++ , it could be a very long one, you can skip all the line and go to the probably last line where it say

PROXY YourProxyAddress: Port

Take note of that address, and under your Windows Home User ( C:\Users\YourUser ), search for .gitconfig file, open it in an editor and you need to add under http tag(create it if is not there)

[http]
       # This is a comment, also add the sslverify, in order to not use any 
       # certificate
    sslverify = false 
    proxy = YourProxyAddress: Port

After these steps if we run again the clone command, we will be succefull cloned our remote repository :

.

This could have been achieved also by Git CLI withouth adding manually the proxy server address in .gitconfig, as explained here .

Or even better provide also the Git credential b CLI, as from here.

But in this way one could come to some issue, has happened to me because depending of the password some special caracthers for bash( as it is the Git CLI) need to be escaped such @ or !, personally I had some hard time doing that even I used the right encoding for those, moreover in this way Git store those into .gitconfig and may be not advisable store them in a computer that you don't use regulary or you are not the Admin Rights.

The first approach let you then provide your credential via CLI and also in Visual Sudio code via Terminal or Pallet if using a plugin, for the specific task(pull, push etc).

At this point you could be setted, but only if you are satisfied with the default account for Git that will be those of your User under you login in the machine.

In order to customize those, you need to tell git which account to use, the run the following in the [commands] (https://stackoverflow.com/questions/22844806/how-to-change-my-git-username-in-terminal) :

git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git config --global user.password "your password"

At this point you are all set as well with Visual Studio Code, if the Azure account is created( but will work with any CLOUD Service), for any Git task that can be done via HTTP.

As the post was longer as planned I will be a II Part regarding the SSH protocol and following regarding specifically VS Code Online and Visual Studio Remote development

So I decided to investigate the topic further to clarify it to myself and to the readers bringing as much as possible updated example.

Let's start from the docs that recommend the use of function expression in this way:

class Foo extends Component {
  constructor(props) {
    super(props);
    this.handleClick = this.handleClick.bind(this);
  }
  handleClick() {
    console.log('Click happened');
  }
  render() {
    return <button onClick={this.handleClick}>Click Me</button>;
  }
}

So with a class based Component aka a component that has to manage the state, then when we want do something with the data, this is still the way to go because it was like this from the beginning but also for choice to bind the this to the class constructor.

The same with arrow function is still on Stage 3 Proposal, but would be like:

class Foo extends Component {
  handleClick() {
    console.log('Click happened');
  }
  render() {
    return <button onClick={this.handleClick.bind(this)}>Click Me</button>;
  }
}

So when which one is the preferred one?

Well it depends, as usual.

First if depends if we have Functional Components that do not change the state, in this case the arrow function enable us to avoid to use bind as in arrow function the this has a context lexical scope, meaning its value is the one outside of the arrow function environment, as arrow functions do not have their own this, so we are sure of its value or we want that it is exactly the outside's function one!

This is the advantage, on the contrary there is a disadvantage, each arrow function does create a new object instance once is called, and so in React case each time the Component is rendered.

Let's see in code:

import React from 'react'
import ReactDOM from 'react-dom'

class Button extends Component {
  render() {
    return (
      <button
        onClick={() => this.setState({ backgroundColor: 'red' })}
        style={this.state}>
        Set background to red
      </button>
    )
  }
}

ReactDOM.render(
  <Button />,
  document.getElementById('root')
)

In this particular case actually the arrow function way is the only way to avoid a bag regarding this that its value is dynamically set.

As indeed in this case

import React from 'react'
import ReactDOM from 'react-dom'

class BrokenButton extends Component {
  render() {
    return (
      <button onClick={this.handleClick} style={this.state}>
        Set background to red
      </button>
    )
  }

  handleClick() {
    this.setState({ backgroundColor: 'red' })
  }
}

ReactDOM.render(
  <BrokenButton />,
  document.getElementById('root')
)

The color won't change at least we had bind the this as above, because the handleClick method isn’t a method at all! JavaScript doesn’t actually have methods. It only has functions. And the value of this inside those functions has some funny rules. In this case, those rules cause this to be null.

The thing to watch out with use arrow function in rendering part of a React component is that every time a new object is created and so new reference is created and this is true also with arrow function.

So The main reason for taking the above approach in which we use in the render an arrow function is if you want to pass parameters to the handler beside the native event that get passed, meaning you want to pass a parameter upwards.

As mentioned, this will create a new function instance on each render. But there is a better approach in this case.

A better approach would be to create component composition. You can create a child component that wraps the relevant markup, will have it's own handler and will get both the data and handler as props from the parent.

The child component will then invoke the handler that it got from the parent and will pass the data as a parameter.

Writing regarding this subject where much useful many relevant questions and answer on Stackoverflow such, and I plan to expand the topic with more example

https://stackoverflow.com/questions/52031147/react-which-is-recommended-arrow-or-normal-function

https://stackoverflow.com/questions/48699573/correct-use-of-arrow-functions-in-react

https://stackoverflow.com/questions/45053622/how-to-avoid-bind-or-inline-arrow-functions-inside-render-method/45053753#45053753

https://stackoverflow.com/questions/34361379/are-arrow-functions-and-functions-equivalent-exchangeable

Also those other articles:

https://frontarm.com/james-k-nelson/when-to-use-arrow-functions/

https://medium.com/@oleg008/arrow-functions-in-react-f782d11460b4

https://www.freecodecamp.org/news/react-binding-patterns-5-approaches-for-handling-this-92c651b5af56/

This will be an introduction list on the essential loaders and plugins one need to have installed in order to work with styles as CSS, SASS files and files in general such for example images.

The list will not be complete and will been update in the future based on the package plugins updates / deprecation and readers feedback.

So then let's start.

As a recup let's remember what loaders are:

Loaders allow webpack to process other types of files and convert them into valid modules that can be consumed by your application and added to the dependency graph. They are transformations that are applied to the source code of a module. They allow you to pre-process files as you import or “load” them. Thus, loaders are kind of like “tasks” in other build tools and provide a powerful way to handle front-end build steps. Loaders can transform files from a different language (like TypeScript) to JavaScript or load inline images as data URLs. Loaders even allow you to do things like import CSS files directly from your JavaScript modules!

So now that we understand why this one should be the first loader to consider to install in your frontend application part, if you want webpack to be able to include .css file into the bundler file then you need this two loaders :

css-loader and style-loader

The first interprets @import and url() like import/require() and will resolve them. Basically turns .CSS into Commonjs.

This is how you setup it into the webpack file:

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
};

So then we then will have:

 use: ['style-loader', 'css-loader', ],

Here we need to note that webpack does start to "use" first the last-right element of the use array, so in this case the css-loader loader that let webpack include into the bundler css code as Javascript one.

Of course we need to import the .css file into the entry point where the loader will be looking for the .css file.

The style-loader instead inject CSS into the DOM.

The next one is essential only if you want to use .scss instead of .css files. They can be used both but for now we show the SASS one only used.

**sass.loader ** --> Turns scss into standard css

that import in the entry point the sass.file or the second part vendors such bootstrap.

Now let's move to plugins that are from the official webpack docs , defined as such:

Plugins are the backbone of webpack. webpack itself is built on the same plugin system that you use in your webpack configuration! They also serve the purpose of doing anything else that a loader cannot do. You can find an extensive list here.

The one you probably are going to use if you want to make your life easier, is the

HtmlWebpackPlugin --> simplifies creation of HTML files to serve your webpack bundles.

This is especially useful for webpack bundles that include a hash in the filename which changes every compilation. You can either let the plugin generate an HTML file for you, supply your own template using lodash templates, or use your own loader.

This will indeed make sure that if you do use cache busting feature as in filename:

const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
 mode: "production",
  output: {
    filename: "[name].[contentHash].bundle.js",
    path: path.resolve(__dirname, "dist")
  },
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: ['style-loader', 'css-loader'],
      },
    ],
  },
};

that is the ability of webpack to generate a file name of the bundler file based on an Hash function( e.g the md5 algorithm ), so a filename that change based on the file content, html-webpack-plugin will include every time the new filename as the source of the bundle cleaning old one, still keeping the feature of cache busting.

So this is how this plugin should be used once have installed it:

var HtmlWebpackPlugin = require('html-webpack-plugin');
var path = require('path');

module.exports = {
  entry: 'index.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: "[name].[contentHash].bundle.js",
  },
  plugins: [new HtmlWebpackPlugin()]
};

With this basic setting it will generate a dist/index.html containing the following:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>webpack App</title>
  </head>
  <body>
    <script src="index_bundle.js"></script>
  </body>
</html>

At this point the plugin won't know which template use, so we need still to tell it either to use a plan template.html or a library or connect to a template system.

Going for the simply solution, providing a template.html file as an object:

 plugins: [new HtmlWebpackPlugin({
 template: 'yourTemplatePath/template.html'
})]

Our template will be used to fill the index.html generated by the plugin with the link to the last bundler with the Hash number concatenated as name.

The next plugin is one that is quite necessary for any project that involve a Development environment and a Production one( well theoretically any).

We will assume then to have 3 different webpack files:

**webpack.common.js **--> containing the setting in common to both production and development

and of course** webpack.dev.js** and a **webpack.prod.js **

Like the following:

webpack.common.js :

const path = require("path");
var HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  entry: {
    main: "./src/index.js",
  },
  module: {
    rules: [
      {
        test: /\.html$/,
        use: ["html-loader"]
      },
      {
        test: /\.(svg|png|jpg|gif)$/,
        use: {
          loader: "file-loader",
          options: {
            name: "[name].[hash].[ext]",
            outputPath: "imgs"
          }
        }
      }
    ]
  }
};

Meanwhile the webpack.dev.js will become simpler as we don't need the template plugin as already in web.common.js, so the** webpack.dev.js** will become:

const path = require("path");
const common = require("./webpack.common");

module.exports = {
  mode: "development",
  output: {
    filename: "[name].bundle.js",
    path: path.resolve(__dirname, "dist")
  }, 
};

similarly the webpack.prod.js that will keep the hash functionality.

We then will include in both the prod and the dev file the common one, but how we can use it?

Here when it come into play the merge plugin, that once installed and required need to be used in this way in both the dev and **prod **version of webpack:

webpakc.dev.js

const path = require("path");
const common = require("./webpack.common");
const merge = require("webpack-merge");

module.exports = merge(common, {
  mode: "development",
    output: {
       filename: "[name].bundle.js",
       path: path.resolve(__dirname, "dist")
    },

 });

Of course we will have different package.json script to run before the webpack.de.js version and then another that will use the webpack.prod.js

This of course require an extra work but enable more flexbility once our application process development start to involve more aspect for development and production but with a large base from both.

For example in development we don't need to build our bundle file everytime so the 2 process could use separate server.

In the webpack.dev.js we can integrate a development server, simply installing it:

npm install webpack-dev-server

That will us enable to be called directly from a package.json script as such:

"start": "webpack-dev-server config webpack.dev.js --open"

Where the open flag let also open a local instance at the default address(localhost:8080).

The advantage f the web-dev-server is also that if does not exist a dist folder where the bundler should be put, it does it create in memory and update it at every change.

At one point we will need also to load some image and this can be manage of course via webpack without put hard coded link.

We will assume to have and image folder under the root/src where image will be uploaded during development.

Unfortunately webpack will not know where this folder is so we need some help and that when it comes in the html-loader :

HTML Loader --> Exports HTML as string. HTML is minimized when the compiler demands.

Here how we should use after have installed:

module: {
     rules: [
       {
          test: /\.html$/,
          use: ["html-loader"]
        },
     ],
},

Unfortunately this plugin will push the image into the js file produced from webpack but we would get an error if not handle image inside webpack.

Here when it comes the File-loader loader that does create dinamically the src for image inside the bundler produced by webpack.

This is how to use it in your webpack.common.js

    {
        test: /\.(svg|png|jpg|gif)$/,
        use: {
          loader: "file-loader",
          options: {
            name: "[name].[hash].[ext]",
            outputPath: "images"
          }
        }
      }

So file-loader will manage to handler the image imported by html-loader and provide an hash name in the above way.

Indeed in the src/index.html we will have :

  <img src="images/YourImageName.hashnumber.ext">

Of course simply add more image extension if you need to support them.

Another plugin that should not be left out is the ** clean-webpack**, as from github repo :

remove/clean your build folder

As we had split the webpack between commom, dev and prod as we don't use the HtmlwebpackPlugin in production every time we build we end up with many bundlers file, but with the above plugin it cleans the output folder and let use only the last bundler.

We use it this way:

const CleanWebpackPlugin = require("clean-webpack-plugin");

module.exports = merge(common, {
    mode: "production",
    output: {
         filename: "[name].[contentHash].bundle.js",
         path: path.resolve(__dirname, "dist")
    },
    plugins: [
         new CleanWebpackPlugin()
    ]
});

We could have the necessity to produce differents bundles based on different libraries( JQuery, React etc).

In this case first we need to change the entry point configuration in the webpack.common.js like:

 entry: {
   main: "yourPathToindex.js",
   vendor: "yourPathtoReactenty.js"
},

The last plugin we are going to list is the one that let improve our user experience.

Indeed having the bundle in the end of the file means that the CSS file are injected together with javascript then only once everything is loaded.

Unfortunately in this way the browser will flag for some milliseconds an error saying that cannot find those styles.

This is when it comes in hand the mini-css-extract-plugin that we will use only in production as load css require time andin development face we don't care that much regarding the flag warning.

webpack.prod.js

  plugins: [
    new MiniCssExtractPlugin({ filename: "[name].[contentHash].css" }),
    new CleanWebpackPlugin()
  ],
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: [
          MiniCssExtractPlugin.loader, //3. Extract css into files
          "css-loader", //2. Turns css into commonjs
          "sass-loader" //1. Turns sass into css
        ]
      }
    ]
  }

What we will get will be a cssfilenameHashnumber.css that will be not minified so still not the best in term of performance.

In order to achieve this performance improvement we can use the optimize-css-assets-webpack-plugin.

It can be used as it says in official repo or in a better way create an apropriate object

optimization: {
    minimizer: [
      new OptimizeCssAssetsPlugin(),
      new TerserPlugin(),
      new HtmlWebpackPlugin({
        template: "./src/template.html",
        minify: {
          removeAttributeQuotes: true,
          collapseWhitespace: true,
          removeComments: true
        }
      })
    ]
  },

We need new TerserPlugin() because OptimizeCssAssetsPlugin override the minifying feature of webpack so it does not then proceed to minify all files but only CSS.

This was a quite extensive list based on the above tutorial but will eventually be added more plugin list and be update depending also on readers feedbacks