DEV Community: Shivam Gupta

Best React Practices

Shivam Gupta — Sat, 28 Aug 2021 19:02:01 +0000

In this blog, I’d be explaining few best practices when working with React/React-Native or any other javascript application. Following are the guidelines will not only reduce the pitfalls but can also make your code more scalable.

Disclaimer: This is an opinionated guide. Decide what works for you and your team and stick with those policies.

Let’s discuss these practices one by one.

TL;DR

Testing, Typescript and Linting.

Testing.

That’s it! There I have said it. Test your WIP (Work In Progress) as much and strictly as you can. If your code is test passed, you are almost there. Do not bypass your work from the testing. Yes, I know you have already heard it like zillionth time but let me write the tools for testing for you.

Jest

The javascript testing framework backed by Facebook, Inc. It is a de-facto standard when it comes to testing JavaScript applications. Works with the project using: Node, Typescript, React, Angular, Bable and more.

Enzyme and/or react-testing-library

It is a powerful tool for Integration testing. Unit tests on their own don’t guarantee that your app will work even if those tests pass because the relationship between the units might be wrong. You should test different features with integration tests.

Cypress

Cypress is an end-to-end testing tool. It enables you to write unit tests and integration tests too. These tests are usually run on the entire application.

"Fast, easy and reliable testing for anything that runs in a browser.”

Linting.

Your test passed codebase can still be a pain for the other developers. If a codebase does not follow strict coding standard guidelines — it will directly impact its scalability. Scalable code is as important as bug-free and tested code. ESLint lets you put uniform, standard coding guidelines. The project should follow one and only one standard protocol. For more details, please check my blog on ESLint.

Typescript.

TypeScript is a strongly typed programming language that builds on JavaScript giving you better tooling at any scale. TypeScript adds additional syntax to JavaScript to support a tighter integration with your editor. Catch errors early in your editor. Using Typescript in trivial applications is often looked like little over the top. However, if your project is medium to large scale you should consider developing it in Typescript.

While Typescripting, Testing and Linting cover the major part following are few other practices that you can follow:

Libraries

With the npm, you have thousands of third party libraries at your hand that you can use. But you should be cautious of the third parties you are adding to your project. In general, the more third parties you add, the more control you lose over your project, the bulkier it gets. Here are few rules to help you out.

Check how often the dependency gets updated or maintained. You can visit the Github repository and check the open issues and the recent activities.
You can check the weekly downloads. It gives you a brief idea about the popularity of that dependency.
Make sure the dependency you are adding is backed by the authentic contributor(s).
You should also consider checking the unpacked size, last published date.

Strict CI/CD

It is needless to say. You should set up the CI/CD that runs all the test cases, lint scripts. Feel free to set up the lenient CI/CD if you want bugs to enter in your production. Consider using Github actions or CircleCI. Every time someone merges or pushes their changes into the main branch there should be an action that runs all the test scenarios and lint scripts beforehand.

Comments

Do you think your piece of code requires commenting for better understanding? Chances are, you are right. Write comments when and where it is necessary. However, you should consider few important things:

Update your comment(s) when required.
Feel free to mention Tickets ID for reference in the comment.
Do not write unnecessary comments. For example:

// assigning 10 to the x

let x = 10;

Code Refactoring & maintaining the docs

They say that the first rule of programming is,

“dOn’T tOuCh If iT’s wOrKiNG!”

I don’t want to sound rude but, I do not believe this. I believe — improve it if it can be improved. Optimize if it can be optimised. With the luxury of having a version control system, I wouldn’t even mind experimenting with it. You should consider your codebase refactoring every once in a while. Monthly if not weekly.

Contribute? Found a mistake?

Feel free to connect with me, I’d love to hear from you! Thanks for reading.

Containment, Specialization and Inheritance in React-Native/React

Shivam Gupta — Sat, 03 Jul 2021 17:37:00 +0000

In this blog, I’m going to talk about Containment, Specialization and Inheritance in React-Native/React, the difference between them and how you can use them to reuse your code.

First, while the examples shown below are related to react-native, the theory is also applicable to react. The concepts might help you to go DRY. Let’s discuss these points one by one.

Containment

When you wrap your component(s) within a higher-order component, it’s a containment. Some components don’t know their children ahead of time. Some common cases are Sidebar, Dialog. And for the sake of reusability, some components better be generic.

The following problem can make this clear:

Problem Statement:

We have a table of n rows and two columns. The columns can hold not just the text but any other JSX component (Button, Image, Icon) too. However, it’s is known that it’s going to be a text for 80% of the time.

Solution:

React containment model can be useful in these cases.
The idea is to create a wrapper — GenericRow that can hold any JSX component. Furthermore, we can create a CustomRow for Text component only. This is also called Specialization. Yes, I know that I’ve been talking a lot, so let me write the code for you:

/* Generic Row that doesn’t know about its children */

const GenericRow = (props) => (
 <View {...props}>
   /* Left column or Left child */
   <View style={styles.column}>{props.left}</View>

   /* Right column or Right child */    
   <View style={styles.column}>{props.right}</View>
 </View>
);

/**
 * Specialization of our Generic Row
 * This component is going to be used when it’s known that left and right are texts
 **/
const CustomRow = ({ left, right, ...props }) => (
 <Generic
   { ...props }
   /* Left child */
   left = { <Text>{left?.toString()}</Text> }
   /* Right Child */
   right = { <Text>{right?.toString()}</Text> }
 />
);

/* Child of CustomRow | First Row */
const NameRow = (props) => (
 <CustomRow left="Developer’s Name" right="Shivam Gupta" />
);

/* Second Row for the age */
const AgeRow = (props) => <CustomRow left="Age" right="22" />;

/* Action: Connect | Third row */
const ConnectActionRow = (props) => (
  /* Notice Generic Row not a CustomRow! */
 <GenericRow left = { <Text>Connect</Text> } right = {<Button title="Hit me!" />} />
);

Here, CustomRow is a specialization of the GenericRow which is going to be used frequently as per the problem statement. Notice that the ConnectActionRow component is contained by the GenericRow and not by the CustomRow, unlike the NameRow and AgeRow.

Just using concepts of containment, we have the code which is easier to read, debug and maintain.

Now let’s talk about specialization.

Specialization:

Sometimes a component is a special case of the other component. For example, Error Text (traditionally, bold and red) is a special case of Text.

The following problem will help you understand this better.

Problem Statement:

You’re creating a medium-sized non-trivial react-native application that is going to have 20 screens. You require to prompt the danger text (for validation error) on at least 7 to 8 screens.

Solution:

You’ll create a separate component for it. Of course! Any sane developer would do that. If that’s the case you already know about Specialization. For beginners, let me just write a code:

const Error = ({ children, fontFamily, style }) => (
 /* User may overwrite the color, or fontWeight using his own style. */
    <Text 
      style={[
         { color: “red”, fontWeight: "bold" }, 
         /* Notice this written after the our style, letting user to overwrite color and fontWeight. */
         { ...style}
      ]}
    >{children}</Text>
);

Again, the idea for this implementation is to use the DRY principle and at the same time allow the user of this component to overwrite our default stying whenever the developer wants.

Inheritance

React neither prefers nor does provide anything much for inheritance. Most of the time, you’re not going to need it. Whatever you could do using inheritance, you can achieve the same using Containment or Specialization. The following is the statement from the react’s official documentation:

“At Facebook, we use React in thousands of components, and we haven’t found any use cases where we would recommend creating component inheritance hierarchies.”

Difference between Containment, Specialization and Inheritance

While Containment, Speicializtion and Inheritance may sound similar but they are very different. The following may help you understand it.

The table CONTAINS/HAS rows. Neither table is a specialization of rows, nor it’s an inheritance.
Pulsar IS a Bike. Neither this is an example of containment nor specialization.
Welcome Dialog is a special case of Dialog. Neither this is an example of containment nor inheritance.

The difference between containment and inheritance is of IS/HAS relationship.

Conclusion

The main objective of the containment and specialization concept is to follow the DRY (Don’t Repeat Yourself) principle. Because redundant code is hard to maintain, harder to debug and using these concepts will make your code maintainable and less error-prone.

ESLint: What, Why, When, How

Shivam Gupta — Sat, 19 Jun 2021 18:26:41 +0000

What is ESLint?

ESLint is an open-source Javascript linting utility originally created by Nicholas C. Zakas in June 2013. It is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines. ESLint is written using Node.js to provide a fast runtime environment and easy installation via npm.
With ESLint you can impose the coding standard using a certain set of standalone rules. Yes, you can turn those rules on and off. These rules are completely pluggable.

Why use ESLint?

JavaScript, being a dynamic and loosely-typed language, is especially prone to developer error. ESLint lets you put guidelines over coding standard and helps you to minimize those errors. The main reason for imposing those guide is because every developer has her style of writing (like naming conventions/tabs/single or double quotes for a string). And, with different styling techniques, your codebase may look weird, more error-prone and vulnerable. Especially when you’re dealing with Javascript this could cause pitfalls you’d never want to deal with.

When to use it?

Honestly, I prefer to use it no matter the project size or the team. But you should consider having it for any medium to large-scaled non-trivial Javascript/Typescript project or/and you’ve got quite a team of developers to deal with. In either case, you have to impose common, standard coding practice/guidelines.
Linting tools like ESLint allow developers to discover problems with their JavaScript code without executing it. One of the main the reason for ESLint was created was to allow developers to create their own linting rules. You can use ESLint in any application that runs on Javascript/Typescript:

React/React Native
Angular
Node.

How to use it?

Enough talk, eh? Here’s how you can install it.

Install it

Prerequisites: Node.js (^10.12.0, or >=12.0.0)
You can install ESLint using npm or yarn:

$ npm install eslint --save-dev
# or
$ yarn add eslint --dev

Note: It is also possible to install ESLint globally rather than locally (using npm install eslint --global). However, this is NOT recommended, and any plugins or shareable configs that you use must be installed locally in either case.

Initialize it

After installing it, initialize it with the following command:

$ npx eslint --init
# or
$ yarn run eslint --init

Note: — init assumes you have a package.json file already. If you don’t, make sure to run npm init or yarn init beforehand.

Configure it

The moment you’re done with the installation and initialization you’ll have a .eslintrc.{js,yml,json} file in your directory. In it, you’ll see some rules configured like this:

{
    "rules": {
        "semi": ["error", "always"],
        "quotes": ["error", "double"]
    }
}

Use it

If you’re here that means you’ve successfully configured the ESLint. Here’s how you can use it:

$ npx elinst <your file>.js
# or 
$ npx eslint <folder containing js files>

You can also add lint in yourpackage.json file (if not already added)

"scripts": {
  ...
  "lint": "eslint .",
  ...
}

Congrats!

You’ve successfully made your codebase look a lot cleaner and better than ever in just a few steps.