DEV Community: Anton Melnyk

Redux actions are not setters

Anton Melnyk — Mon, 19 Apr 2021 12:35:20 +0000

One of the common misconceptions and myths when working with Redux is that actions are setters to the Store.

It's tempting to just add an action like setMyPropertyValue and then inside reducer check for this action and just set the property value to action.value:

// "Setter" action
const setMyProperty = value => ({ type: "SET_SOMETHING", value });

// "Setter" in reducer
case "SET_SOMETHING":
  return {
    ...state,
    myProp: action.value
  };

While sometimes action really can be a glorified property setter, this pattern is usually a code smell and a sign of the wrong usage of Redux.

One of the main advantages and ideas of Redux is decoupling of "what happened" from "how the state was changed". That's the reason why we actually need actions and reducers separated and one of the reasons to use Redux at all.

In the action object, we are describing what happened in the application. In the reducers, we are describing how to react to that application event. In the core of the Redux is a "one to many" relationship. One action "triggers" many reducers, each of which changes its own part of the state.

If we're doing actions that begin with "set...", we are losing the "one to many" relationship between that action and reducers. In this way, we are coupling the action to specific state property. This, in turn, can lead to other problems.

Too granular dispatching

When actions become setters, thunk action creators can become functions that dispatch multiple actions in a row to perform a "state change transaction". Dispatches become too granular and meaningless, leaking state update logic to the thunk action creators functions. For example, that's how hypothetical bad action creator that adds item in the basket could look:

export const itemAdded = item => (dispatch, getState) => {
    dispatch(addItem(item));
    dispatch(totalCostUpdate(item.price));
    dispatch(applyDiscount(getState().totalCost));
};

Here we have a basket update logic leaked to the action dispatch itself. Clearly, we could have just a single dispatch for "ADD_ITEM" and reducers should add an item, calculate the total cost and apply the discount. Although actions listed here do not have "set" in their names, they are still acting like setters for specific properties and potentially could be removed in favor of adding this logic to reducers.

Having potentially wrong state

Every dispatch and resulted state change is independent. That means that following the example above we have 3 different state shapes that change each other in a row. Is it valid to have an item added, but the total cost not updated? In terms of application logic probably not.
Having an action creator like this opens a possibility that another part of the application accidentally dispatches the "addItem" action independently and that will leave to a state that is not valid. Catching bugs like this with Redux is easy by just following Redux DevTools state changes, but instead of catching bugs and having to remember that "when adding item we must change 3 state properties" we should have Redux to remember that for us by having those properties reacting in a reducer to a single action instead 3 of them.

Decreasing performance

On every dispatch, Redux iterates all subscriptions and runs all selector functions each subscription has (technically details on this depend on the framework you are using Redux with). Some selectors can potentially have calculations of the derived state, which can make the situation even worse if selectors are not memoized.

While JavaScript is fast enough to run hundreds of functions per milliseconds and is not usually the performance bottleneck, we don't have to waste processor power, especially considering some low-end mobile devices. A smaller amount of actions can make our subscriptions run faster.

Losing centralization

One of the goals of Redux is to have the state updated by pure functions. If actions act as setters, we stop having application logic centralized and contained in pure reducers, but instead, we have it leaked and spread across action creators or even worse - some UI components.

Increasing boilerplate code

Each action involves some degree of "boilerplate" code. Especially in TypeScript, we usually need to define:

action type string constant via enum
type of the action object
action creator function
handle new action in reducer

This adds more auxiliary lines of code, but it has a purpose for real actions - strict typing, organization of code, and better visibility of how the application state can be changed. Ideally, opening the file with declared action types constants should give the developer an idea of what can possibly happen in the application. This also helps to onboard new developers on the project and work on it independently in large teams.

When having meaningful actions, we mostly have to add them when starting the project; later we can often reuse existing actions.

But, if we start to add granular setters for each small thing that happens inside the application and is actually part of some other big event, then action types are harder to reason about and the action log becomes polluted, changing too fast in the Redux DevTools which, again, decreases performance and makes state updates less meaningful.

Note: boilerplate can be also avoided by using Redux Toolkit (and probably most of the readers should use it for their Redux applications). But sometimes, it's not desirable (see Immer vs Ramda - two approaches towards writing Redux reducers) or the application you are working on is legacy codebase.

Conclusion

We should aim to treat actions as "events" in Redux applications and make sure we perform updates in reducers. Thunk actions should not be abused and have too many dispatches in a row that act as a single "transaction".

Most of the issues mentioned above are basically a reason why we are using Redux. We use it to have centralized complex state updates that are easy to reason about and work with within large teams. Actions that act as setters work against that goal.

Understanding JavaScript type conversions

Anton Melnyk — Sat, 31 Aug 2019 23:20:28 +0000

Introduction

Probably the most confusing part of JavaScript is how it works with types. A lot of weirdness can be achieved thanks to JavaScript being a flexible and forgiving language with a rich history. You've likely seen fun things like that:

(NaN+Object()["to"+String["name"]]["call"]())[11] // Produces letter "U" 😮

The example above is too extravagant, but in general good developers should understand all the lowdowns of the programming language they are using.

Let's clear all the misconceptions about how and when Javascript converts types.

What types are in JavaScript?

Values in JavaScript are one of the next types:

// We can use typeof function to get the type of the value

typeof undefined // "undefined"
typeof 42 // "number"
typeof "hello" // "string"
typeof true // "boolean"
typeof { name: 'Jhon' } // "object"
typeof alert // "function"
typeof Symbol("id") // "symbol"

typeof null // "object"

This should be pretty self-explanatory if you worked with JavaScript already.

The null value of course is not an object though. Its type is "null". Yet for the historical reasons typeof function returns "object" for the null value.

As JavaScript is a language with weak typing so it will try to do implicit conversions between the types when it happens. But, implicit is a dangerous word to use in a JavaScript world!

What is type conversion?

When operand or a function parameter doesn't have expected type...

3 > "3"  // Expects number, given string
3 + true // Expects number, given boolean
alert(3) // Expects string, given number
alert({ name: 'John' }) // Expects string, given object

Javascript converts the value to the expected type following specific rules.

Let's examine each of the most possible of them that you can meet in the code:

String type conversion

String type conversion applies when the given value is expected to be a string. The most basic example is the alert function:

alert(3)    // 3 becomes "3"
alert(true) // true becomes "true"
alert(null) // null becomes "null"

As you can see, string conversion happens as you would expect in an obvious way.

Number type conversion

Number type conversion can be met in the math expressions and comparisons. Here is where usually a lot of confusion comes from.

2 * "3" // 6
6 / "2" // 3
3 - "1" // 2

3 + "3" // "33" 🤬

Excuse me? Yes! The + operator actually works a bit differently. If one of the operands is a string, then all other operands are converted to string too and it works like string concatenation, not like the math expression:

// One of the operands is string "2"
// JavaScript will convert every other operand to string too
1 + "2" + true // The result is "12true"

In arithmetic expressions, boolean, null and undefined convert to a numbers as following:

1 + true      // true becomes 1, result is 2
1 + false     // false becomes 0, result is 1
1 + null     // null becomes 0, result is 1
1 + undefined // undefined becomes NaN, result is NaN

That's it. No ✨ magic, only strict rules!

Boolean type conversion

This type of conversion happens in logical operations. It follows strict rules too yet they are mostly obvious:

0, NaN, undefined, null, "" are converting to false
everything else, including objects, to true

if ("hello") // true
if (0)       // false
if ({})      // true

Type conversions for objects

What JavaScript is going to do if it needs to convert an object to string or number? Let's see:

parseInt({}) // NaN (converted to number)
alert({})    // "[object Object]" (converted to string)
alert([])    // ""

These are default converted values. You rarely would want to convert objects into primitives... Still, if your code needs a more meaningful conversion you would need to know how to set the conversion rules explicitly.

When converting the object type (not array), JavaScript tries to find and call three object methods:

Call obj[Symbol.toPrimitive](hint) – the method with the symbolic key Symbol.toPrimitive.
Otherwise if type of hint is "string" call obj.toString() and obj.valueOf(), whatever exists.
Otherwise if type of hint is "number" or "default" call obj.valueOf() and obj.toString(), whatever exists.

The hint is a type of the primitive the object is going to be converted to.

As you can see, you will need to explicitly set Symbol.toPrimitive property for your objects in case you need meaningful visualisation of your object.

Symbol.toPrimitive

Let's create an object and set Symbol.toPrimitive property.

const obj = {
  name: "Default conversion"
}

const country = {
  name: "Estonia",
  population: 1291170,

  [Symbol.toPrimitive](hint) {
    // For string conversion
    if(hint == "string") {
      return `Country: ${this.name}, population: ${this.population}`
    }

    // Otherwise number conversion
    return this.population
  }
}

alert(obj) // "[object Object]"
alert(country) // "Country: Estonia, population: 1291170"
alert(country + 1) // 1291171

Comparison and type conversion

There is two specific comparison rules.

When doing a non-strict comparison Javascript converts operands to numbers if operands have different type:

0 == "0"  // true. String is converting to a number
0 === "0" // false. Strict comparison compares types too!
"0" != "" // true. There isn't type conversion

null == undefined! There isn't any type of conversion here and these values have a different types! Yet in non-strict comparison undefined equals null and undefined by design:

null == undefined // true. God bless JavaScript ❤️

Conclusion

Here we described the main rules and approach in which JavaScript makes types conversions. If you carefully observe all these rules you will find that they are basically obvious in most cases. Anyway, in the real production code I would encourage you to avoid implicit type conversions and weird comparisons:

For example, values received from user input will be in the string type. Convert them to number explicitly before using it further:

// ... imagine we handled user input event
const money = parseInt(event.target.value);
alert(typeof money == "number"); // true. Now we can safely use money as a number

Concatenate string using template literals instead + operator:

// Can be confusing to read because the result can vary depending on operands types
const result = one + two 

// Explicitly concatenated string
const text = `${one}${two}`

Use strict comparison for comparing values with different types to avoid implicit conversion to number:

const something = 0;
alert(something == false)  // true
alert(something === false) // false

That's it! I hope you found this little guide helpful and now you can better understand types and implicit conversions in JavaScript.

Now you should be able to decifer the article image:

{} + {}    // NaN, because object is converting to NaN
[] + []    // "", because array is converting to ""
0 == "0"   // true, because "0" is converting to 0
0 == ""    // true, because empty string is converting to 0
"" != "0"  // true, because operands are the same type (string) and no conversion happens

Happy coding! ❤️

How to configure Webpack 4 or 5 from scratch for a basic website

Anton Melnyk — Wed, 13 Mar 2019 19:31:41 +0000

🌼 Introduction

Hello, reader! 🐱

As you may know, configuring Webpack can be a frustrating task. Despite having good documentation, this bundler isn't a comfortable horse to ride for a few reasons.

Webpack team is working really hard and relatively quickly developing it, which is a good thing. However, it is overwhelming for a new developer to learn all stuff at once. Tutorials are getting old, some plugins break, found examples can be confusing. Sometimes you can be stuck at something trivial and google a lot to find some short message in GitHub issues that finally helps.

There is a lack of introductory articles about Webpack and how it works, people rush straight to tools like create-react-app or vue-cli, but one sometimes needs to write some simple plain JavaScript and SASS with no frameworks or any fancy stuff.

This guide will look at step-by-step Webpack configuration for ES6, SASS, and images/fonts without any framework. It should be enough to start using Webpack for most simple websites or use it as a platform for further learning. Although this guide requires some prior knowledge about web-development and JavaScript, it may be useful for someone. At least I would be happy to meet something like this when I started with Webpack!

🎈 Our goal

We will be using Webpack to bundle our JavaScript, styles, images, and fonts files together into one dist folder.

Webpack will produce 1 bundled JavaScript file and 1 bundled CSS file. You can simply add them in your HTML file like that (of course you should change path to dist folder if needed):

<link rel="stylesheet" href="dist/bundle.css">
<script src="dist/bundle.js"></script>

And you are good to go 🍹

You can look at the finished example from this guide: 🔗link.

Note: I updated dependencies recently. This guide applies to the latest Webpack 5, but config keeps working for Webpack 4 in case you need it!

🔧 Get started

1. Install Webpack

We use npm: $ npm init command to create a package.json file in a project folder where we will put our JavaScript dependencies. Then we can install Webpack itself with $ npm i --save-dev webpack webpack-cli.

2. Create entry point file

Webpack starts its job from a single JavaScript file, which is called the entry point. Create index.js in the javascript folder. You can write some simple code here like console.log('Hi') to ensure it works.

3. Create webpack.config.js

... in the project folder. Here is where all ✨ magic happens.

// Webpack uses this to work with directories
const path = require('path');

// This is the main configuration object.
// Here, you write different options and tell Webpack what to do
module.exports = {

  // Path to your entry point. From this file Webpack will begin its work
  entry: './src/javascript/index.js',

  // Path and filename of your result bundle.
  // Webpack will bundle all JavaScript into this file
  output: {
    path: path.resolve(__dirname, 'dist'),
    publicPath: '',
    filename: 'bundle.js'
  },

  // Default mode for Webpack is production.
  // Depending on mode Webpack will apply different things
  // on the final bundle. For now, we don't need production's JavaScript 
  // minifying and other things, so let's set mode to development
  mode: 'development'
};

4. Add npm script in package.json to run Webpack

To run Webpack, we have to use npm script with simple command webpack and our configuration file as config option. Our package.json should look like this for now:

{
  "scripts": {
    "build": "webpack --config webpack.config.js"
  },
  "devDependencies": {
    "webpack": "^4.29.6",
    "webpack-cli": "^3.2.3"
  }
}

5. Run Webpack

With that basic setup, you can run $ npm run build command. Webpack will look up our entry file, resolve all import module dependencies inside it and bundle it into single .js file in dist folder. In the console, you should see something like this:

If you add <script src="dist/bundle.js"></script> into yout HTML file you should see Hi in a browser console!

🔬 Loaders

Great! We have standard JavaScript bundled. But what if we want to use all cool features from ES6 (and beyond) and preserve browser compatibility? How should we tell Webpack to transform (transpile) our ES6 code to browser-compatible code?

That is where Webpack loaders come into play. Loaders are one of the main features of Webpack. They apply certain transformations to our code.

Let's add to webpack.config.js file new option module.rules. In this option, we will say Webpack how exactly it should transform different types of files.

entry: /* ... */,
output: /* ... */,

module: {
  rules: [
  ]
}

For JavaScript files, we will use:

1. babel-loader

Babel is currently the best JavaScript transpiler out there. We will tell Webpack to use it to transform our modern JavaScript code to browser-compatible JavaScript code before bundling it.

Babel-loader does exactly that. Let's install it:
$ npm i --save-dev babel-loader @babel/core @babel/preset-env

Now we are going to add rule about JavaScript files:

rules: [
    {
      test: /\.js$/,
      exclude: /(node_modules)/,
      use: {
        loader: 'babel-loader',
        options: {
          presets: ['@babel/preset-env']
        }
      }
    }
]

test is a regular expression for file extension which we are going to transform. In our case, it's JavaScript files.
exclude is a regular expression that tells Webpack which path should be ignored when transforming modules. That means we won't convert imported vendor libraries from npm if we import them in the future.
use is the main rule's option. Here we set loader, which is going to be applied to files that correspond to test regexp (JavaScript files in this case)
options can vary depending on the loader. In this case, we set default presets for Babel to consider which ES6 features it should transform and which not. It is a separate topic on its own, and you can dive into it if you are interested, but it's safe to keep it like this for now.

Now you can place ES6 code inside your JavaScript modules safely!

2. sass-loader

Time to work with styles. Usually, we don't want to write plain CSS. Very often, we use SASS preprocessor. We transform SASS to CSS and then apply auto prefixing and minifying. It's a kind of "default" approach to CSS. Let's tell Webpack to do exactly that.

Let's say we import our main SASS file sass/styles.scss in our javascripts/index.js entry point.

import '../sass/styles.scss';

But for now, Webpack has no idea how to handle .scss files or any files except .js. We need to add proper loaders so Webpack could resolve those files:
$ npm i --save-dev sass sass-loader postcss-loader css-loader

We can add a new rule for SASS files and tell Webpack what to do with them:

rules: [
    {
      test: /\.js$/,
      /* ... */
    },
    {
      // Apply rule for .sass, .scss or .css files
      test: /\.(sa|sc|c)ss$/,

      // Set loaders to transform files.
      // Loaders are applying from right to left(!)
      // The first loader will be applied after others
      use: [
             {
               // This loader resolves url() and @imports inside CSS
               loader: "css-loader",
             },
             {
               // Then we apply postCSS fixes like autoprefixer and minifying
               loader: "postcss-loader"
             },
             {
               // First we transform SASS to standard CSS
               loader: "sass-loader"
               options: {
                 implementation: require("sass")
               }
             }
           ]
    }
]

Note important thing about Webpack here. It can chain multiple loaders; they will be applied one by one from last to the first in the use array.

Now when Webpack meets import 'file.scss'; in code, it knows what to do!

PostCSS

How should we tell to postcss-loader which transformations it must apply? We create a separate config file postcss.config.js and use postcss plugins that we need for our styles. You may found minifying and autoprefixing the most basic and useful plugins to make sure CSS is ready for your real web site.

First, install those postcss plugins: $ npm i --save-dev autoprefixer cssnano.

Second, add them to postcss.config.js file like that:

module.exports = {
    plugins: [
        require('autoprefixer'),
        require('cssnano'),
        // More postCSS modules here if needed
    ]
}

You can dive into PostCSS deeper and find more plugins that suit your workflow or project requirement.

After all that CSS setup only one thing left. Webpack will resolve your .scss imports, transform them, and... What's next? It won't magically create a single .css file with your styles bundled; we have to tell Webpack to do that. But this task is out of loaders' capabilities. We have to use Webpack's plugin for that.

🔌 Plugins

Their purpose is to do anything else that loaders can't. If we need to extract all that transformed CSS into a separate "bundle" file, we have to use a plugin. And there is a special one for our case: MiniCssExtractPlugin:
$ npm i --save-dev mini-css-extract-plugin

We can import plugins separately right at the start of the webpack.config.js file:

const MiniCssExtractPlugin = require("mini-css-extract-plugin");

After our module.rules array where we set loaders add new plugins code where we activate our plugins with options:

module: {
  rules: [
    /* ... */
  ]
},
plugins: [

  new MiniCssExtractPlugin({
    filename: "bundle.css"
  })

]

Now we can chain this plugin into our CSS loaders:

{
      test: /\.(sa|sc|c)ss$/,
      use: [
             {
               // After all CSS loaders, we use a plugin to do its work.
               // It gets all transformed CSS and extracts it into separate
               // single bundled file
               loader: MiniCssExtractPlugin.loader
             }, 
             {
               loader: "css-loader",
             },
             /* ... Other loaders ... */
           ]
}

Done! If you followed along, you could run $ npm run build command and find bundle.css file in your dist folder. General setup now should look like this:

Webpack has tons of plugins for different purposes. You can explore them at your need in official documentation.

🔬 More loaders: images and fonts

At this point, you should catch up on the basics of how Webpack works. But we are not done yet. Most websites need some assets: images and fonts that we set through our CSS. Webpack can resolve background-image: url(...) line thanks to css-loader, but it has no idea what to do if you set URL to .png or jpg file.

We need a new loader to handle files inside CSS or to be able to import them right in JavaScript. And here it is:

file-loader

Install it with $ npm i --save-dev file-loader and add a new rule to our webpack.config.js:

rules: [
    {
      test: /\.js$/,
      /* ... */
    },
    {
      test: /\.(sa|sc|c)ss$/,
      /* ... */
    },
    {
      // Now we apply rule for images
      test: /\.(png|jpe?g|gif|svg)$/,
      use: [
             {
               // Using file-loader for these files
               loader: "file-loader",

               // In options we can set different things like format
               // and directory to save
               options: {
                 outputPath: 'images'
               }
             }
           ]
    }
]

Now if you use inside your CSS some image like this:

body {
  background-image: url('../images/cat.jpg');
}

Webpack will resolve it successfully. You will find your image with a hashed name inside dist/images folder. And inside bundle.css you will find something like this:

body {
  background-image: url(images/e1d5874c81ec7d690e1de0cadb0d3b8b.jpg);
}

As you can see, Webpack is very intelligent — it correctly resolves the path of your url relatively to the dist folder!

You can as well add a rule for fonts and resolve them similarly to images; change outputPath to fonts folder for consistency:

rules: [
    {
      test: /\.js$/,
      /* ... */
    },
    {
      test: /\.(sa|sc|c)ss$/,
      /* ... */
    },
    {
      test: /\.(png|jpe?g|gif|svg)$/,
      /* ... */
    },
    {
      // Apply rule for fonts files
      test: /\.(woff|woff2|ttf|otf|eot)$/,
      use: [
             {
               // Using file-loader too
               loader: "file-loader",
               options: {
                 outputPath: 'fonts'
               }
             }
           ]
    }
]

🏆 Wrapping up

That's it! A simple Webpack configuration for a classic website. We covered the concepts of entry point, loaders, and plugins and how Webpack transforms and bundles your files.

Of course, this is quite a straightforward config aimed to understand a general idea about Webpack. There are many things to add if you need them: source mapping, hot reloading, setting up JavaScript framework, and all other stuff that Webpack can do, but I feel those things are out of the scope of this guide.

If you struggle or want to learn more, I encourage you to check Webpack official documentation. Happy bundling!