DEV Community: Md Zubair Ahmed

Modern ways of UI end to end testing with Cypress

Md Zubair Ahmed — Sat, 22 Aug 2020 06:37:50 +0000

This blog post was originally published in Mattermost blog and cross posted in my blog.

Why write tests ?

The ultimate goal of writing tests should be improving the user’s in-app experience and increasing developers’ confidence in shipping new or improved apps.

The Mattermost team has been continuously writing different types of tests to improve the product. Such extensive automated testing has enabled them to ship a new release—with new features and improvements—every single month for the last few years. Thousands of developers contribute to the codebase. With automated testing in place, the core team at Mattermost can manage, review, and merge such contributions into the product with confidence.

Types of tests

There are many types of tests in software engineering: static tests, unit tests, integrations tests, end-to-end tests, A/B tests, stress tests, smoke tests, and user acceptance tests, to name a few.

If one is starting out, it can be a bit intimidating to see such a huge list. To make matters even worse, when one person is talking about a specific test, it’s quite possible that another person might define that test differently.

In this blog post, we are going to talk a little about static, unit, and integration tests before diving into end-to-end testing.

Static testing

Lets take a look at a small code snippet of our imaginary calculator app:

const add = (...operands) => {
  let sum = 0

  operands.forEach((operand) => {
    sum = sum + operand
  })

  return sums
}

You’ve probably seen it already. The return variable needs to be sum instead of sums. While this example might be simple, other cases—such as accessing unknown objects’ properties error and mixing up variables—can be identified early on by static typing and linting tools such as ESLint, Typescript, and Flow. We group these into static tests.

Unit testing

Let’s now take a look at an actual test. Here, we wrote a small test to test the same add function we saw earlier:

import { add } from './add.js'

test('Adding  function to return correct sum of numbers', () => {
  expect(add(1, 1)).toEqual(2)
  expect(add(2, 3)).toEqual(5)
})

It’s totally fine if you’re not familiar with the syntax. We’ll interpret the code in simple language. We wrote a suite of tests for a single add function. We called the function with certain numbers and expected it to return the correct sum of those numbers. Although our app has other features such as subtraction and division, we are going to test them separately.

Such isolated testing is called unit testing. A unit, however, doesn’t always have to be a function. It could be a class, module, or even an object.

But what if we would like to test more than one such unit in tandem? That’s where Integrations tests come into play.

Integration testing

In these kinds of tests, we verify that more than one unit works harmoniously with each other. Unlike unit tests, integration tests take into account all the working parts of a front-end application, and most calls to backend APIs are mocked. With that setup, it takes relatively less effort to cover a lot of application code and tests run at reasonably fast speeds.

describe('Add page of the app', () => {
  it('Adds number correctly', () => {
    // before the request goes out we need to set up spying
    cy.server()
    cy.route({
      method: 'POST',
      url: '**/add/?operand1=23&operand2=10',
      response: {
        sum: '33',
      },
    }).as('getSumOfNumbersAPI')

    cy.visit('/add-page')

    // # Add the number for first operant
    cy.findByLabelText('Number 1').type('23')

    // # Add the number for second operand
    cy.findByLabelText('Number 2').type('10')

    // # Click calculate button
    cy.findByText('Calculate').click()

    // # Wait for API to get complete
    cy.wait('@getSumOfNumbersAPI').should((xhr) => {
      expect(xhr.status).to.equal(200)
      const { sum } = xhr.response.body

      // * Verify we get the correct sum
      cy.findByLabelText('Sum of number').should('have.value', sum)
    })
  })
})

In the above example, we assumed we were relying on the API to give us the sum of two numbers instead of doing computation on the client side. We don’t have any underlying implementation details but relied on the final result—which is exactly how a user would see and use the application.

We found our inputs where we first entered the numbers and then clicked on the “Calculate” button. We then set up our mock API request at the beginning of our test. That way, when the request actually goes out, our testing framework will catch it and return the mock response.

Finally, the sum of the numbers is verified.

End to end tests

Contrary to all the types of tests above, end-to-end tests run the entire application. This means your client, API, database and third-party services are all included.

As a result, end-to-end testing gives us very high confidence that a critical user flow works efficiently. They are a bit expensive to set up and are a bit slow, and they also require a lot of initial setup. But these tests are closest to how a user would test the application.

describe('Add page of the app', () => {
  it('Adds numbers correctly', () => {
    cy.visit('/add-page')

    // # Add the number for first operant
    cy.findByLabelText('Number 1').type('23')

    // # Add the number for second operand
    cy.findByLabelText('Number 2').type('10')

    // # Click calculate button
    cy.findByText('Calculate').click()

    // # Wait for API to get complete
    cy.wait('1000')

    // * Verify we get the correct sum
    cy.findByLabelText('Sum of number').should('have.value', '33')
  })
})

The next question we probably have is usually something like this: How many of these tests should we write?

Well, there isn’t a rule of thumb that states that an application should have x number of A tests and y number of B tests. There are no definitive percentages or ratios of tests, either. Instead, add confidence to your codebase by using a mix of several different types of tests.

"The more your tests resemble the way your software is used, the more confidence they can give you." - Kent C. Dodds (@kentcdodds) March 23, 2018

// Detect dark theme var iframe = document.getElementById('tweet-977018512689455106-254'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=977018512689455106&theme=dark" }

Getting started with end-to-end testing

There are many tools that help you do end-to-end testing of web applications. Let’s directly dive into Cypress - a testing tool that aims to help you write faster, easier, and more reliable tests. It already has a bunch of assertions and other tools bundled together.

It’s easy to add Cypress to your existing project via npm or yarn.

npm install cypress --save-dev

Once installed, be sure to add a script in your package.json for easy access to the Cypress dashboard.

"scripts": {
    "cypress": "cypress open"
},

When you first run Cypress with the above npm command, it’s going to take a while to install a few prerequisites. Next, you will be presented with the Cypress dashboard which will list all the tests in your app. It’s going to show you some pre-written tests. Check them out to see if you like them and delete them later on.

If you noticed, when you ran the command earlier, a new folder was also created in your root project folder named cypress.

|cypress
-|fixtures
-|integrations
-|plugins
-|support

We will focus on the integrations folder, as that will be the folder where you will be writing your test. Now, before we move on to actually writing a test, let’s install another library which will help us write them from an actual user’s point of view : Testing library

npm install @testing-library/cypress --save-dev

In order for Cypress to be aware of our newly installed "testing-library", we need to add the single command to cypress/support/commands.js:

import "@testing-library/cypress/add-commands";

Now, we are ready to start writing our first end-to-end test!

To remove the friction of creating a functional app ourselves, let’s use the production-ready Mattermost app. To set up your Mattermost development environment, check out their amazing dev docs. The documentation is fairly pretty straightforward, but if you do run into problems, you can always head over to the community chat to get help.

Mattermost uses Cypress intensively to automate testing. Read more about how Mattermost uses Cypress.

Writing your first test

Now that you’re ready to write and run some tests, let’s open the mattermost-webapp in your favorite code editor. It’s a huge codebase because it’s a big and complex product, but give it some time and all of it will start to make sense. We are going to write some tests for Mattermost’s login page.

Next, we head to the e2e/cypress folder and in it the integrations folder. You can see multiple test folders inside integrations. Each folder represents either a feature or component of the app in testing. Find the folder signin_authentication and look for the login_spec.js file.

describe('Login page', () => {
  let config
  let testUser

  before(() => {
    // Disable other auth options
    const newSettings = {
      Office365Settings: { Enable: false },
      LdapSettings: { Enable: false },
    }
    cy.apiUpdateConfig(newSettings).then((data) => {
      ;({ config } = data)
    })

    // # Create new team and users
    cy.apiInitSetup().then(({ user }) => {
      testUser = user

      cy.apiLogout()
      cy.visit('/login')
    })
  })

  it('should render', () => {
    // * Check that the login section is loaded
    cy.get('#login_section').should('be.visible')

    // * Check the title
    cy.title().should('include', config.TeamSettings.SiteName)
  })

  it('should match elements, body', () => {
    // * Check elements in the body
    cy.get('#login_section').should('be.visible')
    cy.get('#site_name').should('contain', config.TeamSettings.SiteName)
    cy.get('#site_description').should(
      'contain',
      config.TeamSettings.CustomDescriptionText
    )
    cy.get('#loginId')
      .should('be.visible')
      .and(($loginTextbox) => {
        const placeholder = $loginTextbox[0].placeholder
        expect(placeholder).to.match(/Email/)
        expect(placeholder).to.match(/Username/)
      })
    cy.get('#loginPassword')
      .should('be.visible')
      .and('have.attr', 'placeholder', 'Password')
    cy.get('#loginButton').should('be.visible').and('contain', 'Sign in')
    cy.get('#login_forgot').should('contain', 'I forgot my password')
  })

  it('should match elements, footer', () => {
    // * Check elements in the footer
    cy.get('#footer_section').should('be.visible')
    cy.get('#company_name').should('contain', 'Mattermost')
    cy.get('#copyright')
      .should('contain', '© 2015-')
      .and('contain', 'Mattermost, Inc.')
    cy.get('#about_link')
      .should('contain', 'About')
      .and('have.attr', 'href', config.SupportSettings.AboutLink)
    cy.get('#privacy_link')
      .should('contain', 'Privacy')
      .and('have.attr', 'href', config.SupportSettings.PrivacyPolicyLink)
    cy.get('#terms_link')
      .should('contain', 'Terms')
      .and('have.attr', 'href', config.SupportSettings.TermsOfServiceLink)
    cy.get('#help_link')
      .should('contain', 'Help')
      .and('have.attr', 'href', config.SupportSettings.HelpLink)
  })

  it('should login then logout by test user', () => {
    // # Enter username on Email or Username input box
    cy.get('#loginId').should('be.visible').type(testUser.username)

    // # Enter password on "Password" input box
    cy.get('#loginPassword').should('be.visible').type(testUser.password)

    // # Click "Sign in" button
    cy.get('#loginButton').should('be.visible').click()

    // * Check that the Signin button change with rotating icon and "Signing in..." text
    cy.get('#loadingSpinner')
      .should('be.visible')
      .and('contain', 'Signing in...')

    // * Check that it login successfully and it redirects into the main channel page
    cy.get('#channel_view').should('be.visible')

    // # Click hamburger main menu button
    cy.get('#sidebarHeaderDropdownButton').click()
    cy.get('#logout').should('be.visible').click()

    // * Check that it logout successfully and it redirects into the login page
    cy.get('#login_section').should('be.visible')
    cy.location('pathname').should('contain', '/login')
  })
})

If you take a quick look at it, you would see the usage of element IDs a lot. This was the first test written at Mattermost, when the team was just getting started with end-to-end testing. Many best practices the team uses now can be found in more recent test files. But somehow, this particular test was left unchanged, so it’s a good opportunity for us to submit an improved test as a pull request.

Each test specification is contained inside the describe block with the main heading of our test suite, which is followed by many it blocks which hold the individual test. You can also see use of before, which is designed to run at the beginning of your test. Without going into much detail, at this point in time it is sufficient for us to know that before creates a new test user and redirects to a login page. Clear out everything inside of the describe except for the before block. Add a new it block with the heading "should render all elements of the page".

describe('Login page', () => {
  let config
  let testUser

  before(() => {
    // Disable other auth options
    const newSettings = {
      Office365Settings: { Enable: false },
      LdapSettings: { Enable: false },
    }
    cy.apiUpdateConfig(newSettings).then((data) => {
      ;({ config } = data)
    })

    // # Create new team and users
    cy.apiInitSetup().then(({ user }) => {
      testUser = user

      cy.apiLogout()
      cy.visit('/login')
    })
  })

  it('should render all elements of the page', () => {
    // start writing here
  })
})

The purpose of our first test is to check if all the elements are rendered in the page. To start off, we verify the URL matches that of the login page. Cypress gives us a command — cy.url — to get the current URL of the page:

// * Verify URL is of login page
cy.url().should('include', '/login');

Notice the use of should. It is the assertion that — when supplied with a suitable chainer and value — creates a test case which Cypress then verifies. In the above code, the line it translates to: A URL should include /login. Cypress runs this case and if it fails, the test is failed — and vice versa.

We can also verify the title of the document with the "cy.title" command. In the before block, we get access to the created teams config object, which contains the document title for the page.

// * Verify title of the document is correct
cy.title().should('include', config.TeamSettings.SiteName);

Now, we need to check if the page contains the fundamental elements required for login, e.g., the email/username field, the password field, and a submit button.

// * Verify email/username field is present
cy.findByPlaceholderText('Email or Username').should('exist').and('be.visible');

// * Verify possword is present
cy.findByPlaceholderText('Password').should('exist').and('be.visible');

// * Verify sign in button is present
cy.findByText('Sign in').should('exist').and('be.visible');

We are finding the input fields by placeholder and the submit button by text, similar to how an actual user would find them. To add multiple assertions, we can chain the and function. Specifically, in the above case, we are verifying if the element is visible to the user and it’s not scrolled off the screen.

We will now try to find out if the page has a forgotten password link and if it points to the correct URL:

// * Verify forgot password link is present
cy.findByText('I forgot my password.')
  .should('exist')
  .and('be.visible')
  .parent()
  .should('have.attr', 'href', '/reset_password')

There’s something new we did in the above assertion; notice the use of parent. To answer that question, let’s look at the HTML structure of I forgot my password:

<a href='/reset_password'>
  <span>I forgot my password.</span>
</a>

Find by text would return us the span element — not the anchor element which actually contains the link. A good practice would have been to use it inside of the anchor itself. But here, due to translation reasons, the team had to use the above way. The parent command helps to go a level up from the span and then we can check if the correct URL exists on the parent <a>.

So far, this is the complete test we have written:

it('should render all elements of the page', () => {
  // * Verify URL is of login page
  cy.url().should('include', '/login')

  // * Verify title of the document is correct
  cy.title().should('include', config.TeamSettings.SiteName)

  // * Verify email/username field is present
  cy.findByPlaceholderText('Email or Username')
    .should('exist')
    .and('be.visible')

  // * Verify password is present
  cy.findByPlaceholderText('Password').should('exist').and('be.visible')

  // * Verify sign in button is present
  cy.findByText('Sign in').should('exist').and('be.visible')

  // * Verify forgot password link is present
  cy.findByText('I forgot my password.')
    .should('exist')
    .and('be.visible')
    .parent()
    .should('have.attr', 'href', '/reset_password')
})

To run the test, you can open your terminal and execute the open cypress command inside of the e2e/ folder. Once the cypress dashboard opens, find the test file name and double-click to run tests:

npm run cypress:open

If your test runs and passes, congratulations on writing an e2e test with Cypress! You can go ahead and write multiple scenarios for login and see your tests running.

Writing another test case

Let’s write another scenario where we type in wrong or non-existing user credentials to login.

Open up a new it block and give it a name “Should show error with invalid email/username and password”. Create a random username and password constant:

it('Should show error with invalid email/username and password', () => {
  const invalidEmail = `${Date.now()}-user`
  const invalidPassword = `${Date.now()}-password`
})

We have the information of an actual user and password from our before block. To be sure, let’s verify our generated credentials aren’t the same as the actual user’s.

it('Should show error with invalid email/username and password', () => {
  const invalidEmail = `${Date.now()}-user`
  const invalidPassword = `${Date.now()}-password`

  // # Lets verify generated email is not an actual email/username
  expect(invalidEmail).to.not.equal(testUser.username)

  // # Lets verify generated password is not an actual password
  expect(invalidPassword).to.not.equal(testUser.password)
})

The expect assertion comes from the Chai js library which is inbuilt in Cypress. Type in the invalid email/username and password in respective fields. Cypress allows you to type in the field value via the type command. It also gives you a command to click which you can use on the submit button.

it('Should show error with invalid email/username and password', () => {
  const invalidEmail = `${Date.now()}-user`
  const invalidPassword = `${Date.now()}-password`

  // # Lets verify generated email is not an actual email/username
  expect(invalidEmail).to.not.equal(testUser.username)

  // # Lets verify generated password is not an actual password
  expect(invalidPassword).to.not.equal(testUser.password)

  // # Enter invalid email/username in the email field
  cy.findByPlaceholderText('Email or Username').clear().type(invalidEmail)

  // # Enter invalid password in the password field
  cy.findByPlaceholderText('Password').clear().type(invalidPassword)

  // # Hit enter to login
  cy.findByText('Sign in').click()
})

Now, we just have to verify if we received the correct error message.

it('Should show error with invalid email/username and password', () => {
  const invalidEmail = `${Date.now()}-user`
  const invalidPassword = `${Date.now()}-password`

  // # Lets verify generated email is not an actual email/username
  expect(invalidEmail).to.not.equal(testUser.username)

  // # Lets verify generated password is not an actual password
  expect(invalidPassword).to.not.equal(testUser.password)

  // # Enter invalid email/username in the email field
  cy.findByPlaceholderText('Email or Username').clear().type(invalidEmail)

  // # Enter invalid password in the password field
  cy.findByPlaceholderText('Password').clear().type(invalidPassword)

  // # Hit enter to login
  cy.findByText('Sign in').click()

  // * Verify appropriate error message is displayed for incorrect email/username and password
  cy.findByText('Enter a valid email or username and/or password.')
    .should('exist')
    .and('be.visible')
})

And voila! You have covered another common test case.

If you would like to see the rest of the improvements I made, check out this pull request.

By now, you’ve seen how easy and enjoyable Cypress makes end-to-end testing. So go ahead and introduce some end-to-end tests in your application!

Setting up webpack for react project doesnt have to be scary

Md Zubair Ahmed — Wed, 22 May 2019 13:12:41 +0000

If you would have asked me few days weeks ago, to setup a complete build and boiler system for new react project, i would have handed you a C.R.A.
So if your response is the same, this blog post is for you.

All the headings point to git commits, so you can browse the project at that title/step state in Github.

Prepare new project

Add package json

Start with an empty folder and run yarn init. This will ask you bunch of questions and make file such as package.json for you. You can fill in your project name and other details.

Install react libraries

Install React and its dom library

yarn add react react-dom

Install webpack

Install core webpack package as *devDependencies and along with that lets also add another two webpack packages; webpack cli, which will be required if we are to run webpack with command line or via npm scripts and webpack-dev-server, this packages gets us up and running our local dev environment without too much hassle of making our own server.

yarn add --dev webpack webpack-cli webpack-dev-server

* devDependencies : are those packages which you would not like to include in the app, but only while building or developing them.

Install prettier

Prettier provides beautifully code formatting. As this has nothing to do with the production code, we are only going to use it while developing code, So install this as devDependency too.

yarn add prettier --dev --exact

There are lots of configurations available to suite your preferences. Head over to docs to configure. Make a new file with name prettier.config.js in your root and Add this just two configuration to it. Feel free to add your own later.

module.exports = {
  trailingComma: 'all',
  semi: false,
}

Write some react code

Create a folder named src in your root and add files index.js to it.
Index.js will be starting point of src. Currently the file is simple, it can be extended later. Follow here to lean how to write react code.

import React from 'react'
import { render } from 'react-dom'

const App = () => (
  <div>
    <h1>React scaffolding kit</h1>
    <strong>An opiniated but customizable react starter kit</strong>
  </div>
)

render(<App />, document.getElementById('REACT_ROOT'))

Run the app

Lets make use of webpack-dev-server we installed earlier to run the app. Its a good idea to have a start script in package.json for easy start up. Add the start script in package.json.

"scripts": {
    "start":"node_modules/.bin/webpack-dev-server",
  },

Now app can start with a simple command in terminal

yarn start

You might see webpack related content appearing in your terminal and finally ending with an error. If error is something on the lines of You may need an appropriate loader to handle this file type or related. Then don't worry you have followed instructions correctly. Lets tackle that error in next section. Go drink a glass of water.
On side note, You might have noticed that webpack was able to identify the code you wrote in src/index.js without you having to provide it with any configuration. Thats because webpack now provides lots of default to get you going soon. Hence placing index.js file under src was the default entry point for webpack.

Transpiling Javascript code

The error we stumbled, means our server wasn't able to understand the code we wrote. It was not compatible with what usually browsers understand. To be able to make it understand we transpile our code to much better browser understanding code with Babeljs.

Install babeljs

yarn add --dev @babel/core

Babel core installs the core functionality of the babel library. In order to make webpack aware of babel and say hey! webpack i want babel to transpile my code before you can do your stuff, we will add another package

yarn add --dev babel-loader

Connecting babel and webpack

By adding the package, webpack still wont be aware of babel. To do that lets add in a configuration file for webpack, and name it webpack.dev.config.js. Why dev in the name ? thats because we would like to keep our production and dev webpack configuration seperate.

module.exports = {
  module: {
    rules: [{ test: /\.js$/, exclude: /node_modules/, use: 'babel-loader' }],
  },
}

With the above we are saying that we would first like to run babel-loader on all js file except the ones in node_modules

Configuring babel

Ok, now you've configured Babel but you haven't made it actually do anything. Lets create babel.config.js in our root. Babel depends on many plugins to do its job. These plugin contains instruction on how to parse the code to more compatible one.
Lets add few plugins that we require. To start, add env preset, which enables transforms for ES2015+ and react preset, which contains most common plugin used along with React. You are free to add and include others. Presets are just a bunch of plugins grouped together.

module.exports = function(api) {
  if (api) {
    //   https://babeljs.io/docs/en/config-files#apicache
    api.cache.using(() => process.env.NODE_ENV)
  }

  const presets = ['@babel/preset-env', '@babel/preset-react']

  const plugins = []

  return {
    presets,
    plugins,
  }
}

Start the app again

Lets run the start command we ran previously. Just a slight modification before we start, we need to tell webpack dev server to read config from the new webpack.dev.config.js file we created earlier.

"start": "node_modules/.bin/webpack-dev-server --config webpack.dev.config.js",

Now you must be seeing that our terminal didn't threw any error when we starter the server. You may now go to the localhost which is mentioned there. Dont be disappointed if you see just bunch of folders over in your website, we havent configured the app to output HTML yet so its just showing us the content of the website instead.

Make app spit html

Webpack contains ecosystem of plugins and loaders. To enable webpack to output html, we are going to add in HTML webpack plugin.

yarn add --dev html-webpack-plugin

Create an html file, which will be served by our app in src folder and add just the simple HTML5 supporting content. Remember we asked react to find element id REACT_ROOT, include that too so that our react apps renders on that element tree.

<!DOCTYPE html>
<html>
  <head>
    <title>React scaffolding kit</title>
  </head>

  <body>
    <div id="REACT_ROOT"></div>
  </body>
</html>

Now we need to configure webpack and ask it to take our html as template and output that instead. All webpack configurations are done in webpack config file. Add a new key plugins for webpack object and import our newly added plugin. The plugin can now be added to plugins array. We will ask it to use the html we just created by providing template option.

const htmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
  module: {
    rules: [{ test: /\.js$/, exclude: /node_modules/, use: 'babel-loader' }],
  },
  plugins: [
    new htmlWebpackPlugin({
      template: './src/index.html',
    }),
  ],
}

Once its done, you can restart the app from start script. Now the app should greet you with React scaffolding kit written big in H1 tags.

Add styling

The app looks rather bland, lets now add the ability to add styles. I am going to add SCSS support because i feel thats the best way to write CSS. Create a new file inside src directory and name it index.scss.

h1 {
  color: blue;
}

Include the styles in your index.js by importing them.

import './index.scss'

But as you have noticed, styling doesnt seems to be picked up by the app. Reason for that there is only so much webpack can do on its own. We will have to provide a way for webpack to include the styling in the app, here comes webpack loaders to rescue.

yarn add --dev style-loader css-loader sass-loader node-sass

Lets look at what those are by adding them in the configuration. Add a new object inside your modeuls/rules in webpack config.

{
    test: /\.scss$/,
    use: [
        "style-loader",
        "css-loader",
        "sass-loader",
    ],
},

Here we are telling webpack to take all our scss files, convert them from scss to css (via sass-loader), resolve css syntax such as import or url (via css-loader) and then take the compiled css and load it up inside <style> under our html's head tag (via style-loader). We have also include node-sass as its required to internal working of sass-loader.

Recap

Congratulations you have now a minimal react app bootstrapped with webpack up and running. If you have come till here, you deserve an applause.

Lets see what have we done till now

[x] Installed required libraries such as react , webpack etc.
[x] Setup prettier for code formatting
[x] Added webpack and a basic configuration
[x] Configured Babel and connected it to webpack
[x] Attached plugin to render HTML from webpack
[x] Styled app with scss and styling loaders

More setup

Communities around react, webpack etc are huge, as such we have some very powerful support libraries, plugins to work with. Let see what more we could do with the above setup

[ ] We could add seperate webpack config for production use.
[ ] Add more webpack plugins as required such as one for copying assets folder, minimizing css files, adding global constants, optimizing the build.
[ ] Have webpack code split with split chunks.
[ ] Have resolved path to our source file, so we can directly import like we do for node_modules.
[ ] Ability to Write and transpile latest ES code with additional babel plugins.
[ ] Make robust server in your choice language for serving production code.
[ ] and much more

The configuration and build one uses for production varies from application to application.

This blog post purpose was to get you familiar with setting up a tiny, less configuration webpack setup for you next react project.

The Abort-able Fetch

Md Zubair Ahmed — Wed, 22 May 2019 13:10:57 +0000

Fetch API have come a long way into becoming a more mature, stable and supportive Web API. We use it extensively in our app. However we weren’t using its abort-able functionality i.e to stop or terminate requests in mid way. Support for abort able fetch was proposed in 2̶0̶1̶5̶ forever ago. Then in 2017 it finally was included in the standard and Edge was first to support it. Now it mostly supported amongst browsers.

The poly fill

Still to support other browsers we use whatwg-fetch , which is a polyfill that implements Fetch whatwg specifications. In addition to that, we had to see if abort able feature was natively supported in the browser ; if not then we use poly filled fetch.

import { fetch as fetchPloyfilled } from 'whatwg-fetch';

const isAbortableFetchSupported = 'signal' in new Request('')

const _fetch = isAbortableFetchSupported ? window.fetch : fetchPloyfilled;

// _fetch is then passed down via props to be used in app

Preparing for aborting

Promises are aborted using the new API provided by the DOM standard. We create a new instance of AbortController. From this controller we grab a reference to AbortSignal object using the AbortController.signal property. This AbortSignal can then be passed on to fetch in its options.

const abortController = new AbortController();
const abortSignal = abortController.signal

..
...

// later in fetch

await this.props.fetch(requestURL, {  
    method: 'GET',
    signal: abortSignal
    })

Aborting

abortController.abort();

Calling the above method will stop your fetch promise and throw an error, which you will need to catch and handle properly.

(err.name === 'AbortError’) {
console.error(’fetch safely aborted for quick stats’, err);
}

Why abort at all?

Are you familiar with “Warning: Can’t call setState (or forceUpdate) on an unmounted component. This is a no-op”. This usually happens if you have a state that is dependent on after effects of your network call, and the context in which that call was made is lost. In simple terms : You went to a page, that started a network request to get list of stuff. You then quickly navigated away to another page. There might be a state responsible for getting list and updating the UI. But now since you navigated away , setState was still called on the former page which is now unmounted. And hence the warning. Its important to take care of it as it leads to memory leaks and uncertainty.

We abort all our network request in componentWillMount

That way we make sure no setStates are called if fetch request are aborted.

The Abominable Fetch

Md Zubair Ahmed — Wed, 22 May 2019 13:09:43 +0000

The first question i get is why use Fetch API instead of Axios library. Well there are many post online which do well to show the similarities and differences in both libraries. Well for us what worked will be discussed some other time.

Lets jump to the post.

Current situation

Our fetch calls are long and cumbersome to write.

await fetch(URL_GOES_HERE, {
   method: 'GET',
   mode: 'cors',
   credentials: 'same-origin',
   headers: {
     Authorization: `token ${this.props.user.loggedInUser.token}`,
     'Accept-Language': language,
     'Content-Type'] = 'application/json'
   }
 }
);

That's a lot of code to just “GET” from the API. Most of the above boiler plate code is repeated for other similar fetch functions across the app. It was evident that mode, credentials, headers can be abstracted out and shared with other fetch functions.

Improvement

To be able to do this effectively, a createFetch wrapper was created which will pass default values to fetch. This new wrapper fetch was then passed down to app via Context React API.

context.fetch = createFetch(window.fetch, {
    baseUrl: context.apiConfig.apiUrl,
    language: store.getState().intl.locale,
    authToken: store.getState().user.loggedInUser.token

You might be wondering where does token come even before app is started. So this context is created after appropriate APIs are called just before starting the app.

The createFetch wrapper consists of defaults which will add to the options of fetch function. As mentioned below :

Headers

let options = {};

// language variable is passed down from createFetch params. 
options.headers[’Accept-Language’] = language;


// Since mostly JSON object is returned. 
options.headers[’Content-Type’] = 'application/json’;


// authToken variable is passed from createFetch params. 
options.headers.Authorization = `token ${authToken}`;

Mode

options.mode = 'cors';

Credentials

options.credentials = 'same-origin';

All the above options are only alloted if they are not explicitly passed. Concluding the defaults we then return the function as follows:

fetch(url, options);

End result

await this.props.fetch(URL_GOES_HERE, {
   method: 'GET'
   }
 );

This resulted in a clean and crisp fetch function. Since it was passed down though context, fetch was accessed via props. However the above function is completely flexible to other values.

The default values can be overridden if required, to bring in different options.

Fixing a very common warning of Sequelize.js

Md Zubair Ahmed — Wed, 22 May 2019 13:08:29 +0000

We had this constant error showing up in our development logs :

squelize deprecated String based operators are now deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/tutorial/querying.html#operators node_modules/sequelize/lib/sequelize.js:236:13

On simple google search, lead me to this huge issue on GitHub https://github.com/sequelize/sequelize/issues/8417.

Conversation over there is huge, there seems to be many potentials solutions, the ones which collaborators most suggested was to disable operator aliasing. So any string based operator will be disabled without any aliases instead symbol based built in operators will be used. This prevents cross site attacks.

const sequelize = new Sequelize(config.databaseUrl, {
  operatorsAliases: false,
})

Follow here for even in detail explanation.

Migrating Bluebird promises to native ones

Md Zubair Ahmed — Wed, 22 May 2019 13:06:27 +0000

We have used bluebird because it was one of the best libraries for promises. But then promises have gained support in both nodejs and browser. That was the easy catch so we planned to remove it from our code base.

The functions we were using of that library were

Promisify

Node js ships with util api which provides same requirement as that of bluebird.

The method works by taking in the common error-first callback style functions and returns a promises.

// Before

import Promise from 'bluebird';
const readFile = Promise.promisify(fs.readFile);

// After

import util from 'util';
const readFile = util.promisify(fs.readFile);

Delay

Purpose of this method is to returns a promise that will be resolved with after given milliseconds. Native way to do this was to promisify setTimeout function.

// Before

import Promise from 'bluebird';
await Promise.delay(1000);

// After

import util from 'util';
const setTimeoutAsync = util.promisify(setTimeout);
await setTimeoutAsync(null, 1000);