---
title: 'Change the color of hidden files and folders in VSCode'
date: '2022-09-04'
slug: 'change-color-hidden-file-folder-name-in-vscode'
thumbnail: '/thumbnails/vscode.png'
tag: 'vscode'
canonicalUrl: 'https:/amanhimself.dev/blog/change-color-hidden-file-folder-name-in-vscode/'
---

Using VSCode, I love switching back and forth between dark and light themes to make things interesting for myself when working. Generally, I prefer a [light-ish dark theme](https://amanhimself.dev/blog/setup-macbook-m1/#themes) such as [fairyFloss](https://marketplace.visualstudio.com/items?itemName=nopjmp.fairyfloss) or Quiet Light that comes pre-installed.

I recently switched to [morgan.code](https://marketplace.visualstudio.com/items?itemName=morgan-codes.morgan-codes-vscode-theme) theme, which uses a set of contrasting colors that are pleasing to my growing old eyes. It is developed by a fellow developer [Morgan Richardson](https://www.instagram.com/morgan.codes/).

Using this theme for a while, I realized I am so used to seeing files and folder names that git ignores in a specific gray color.

The original theme comes with blue-ish (maybe some sort of Cyan or Aqua) color for the ignored files and folders.

![original theme](https://i.imgur.com/J6hik7g.jpg)

To customize this color value, VSCode, provides a property called `gitDecoration.ignoredResourceForeground` which accepts a color value in hexadecimal format. It can be used with the VSCode theme color setting: [`workbench.colorCustomizations`](https://code.visualstudio.com/api/references/theme-color) to override the value that the original theme provides.

```json
// settings.json

{
  // ...
  "workbench.colorCustomizations": {
    // select theme you want to apply color customization value
    "[morgan.codes]": {
      "gitDecoration.ignoredResourceForeground": "#434343"
    }
  }
}
```

That's it! And now, my optic nerves are happy again.

![customized theme](https://i.imgur.com/sk0tFYi.jpg)

VSCode is so customizable that it surprises me at times.


Change the color of hidden files and folders in VSCode

---
title: 'How to add opacity to a Pressable component in React Native'
date: '2022-08-04'
thumbnail: '/thumbnails/react.png'
slug: 'add-opacity-to-pressable-component-react-native'
tag: 'react-native'
canonicalUrl: 'https://amanhimself.dev/blog/add-opacity-to-pressable-component-react-native/'
---

Pressable component was introduced in 2020 as a core component wrapper that can be used instead of existing touchable components in React Native. These touchable components are TouchableOpacity, TouchableHighlight, and TouchableWithoutFeedback. These components include styles and effects that sometimes do not meet the desired outcome on individual platforms (iOS and Android).

The way I see using the Pressable component is that it can be customized in terms of style, appearance, and extended functionality by creating a custom wrapper/component around it. It also offers a lot of props such as `onPressIn`, `onPressLong`, `hitSlop`, `delayLongPress` and so on, that can be used to implement these extended functionalities.

At times, one thing I like to do is to add opacity feedback when the touch is active. It doesn't provide in the form of a prop directly. Something similar to what [activeOpacity](https://reactnative.dev/docs/touchableopacity#activeopacity) prop on TouchableOpacity does.

In this post, let's build a wrapper component that uses Pressable to add opacity feedback to the component.

## Creating a wrapper component

Start by creating a custom Pressable component with no styles of its own so it can be a reusable component.

```jsx
// Pressable.js

import React, { useCallback } from 'react';
import { Pressable as RNPressable } from 'react-native';

function Pressable({ children, style, ...otherProps }) {
  const _style = useCallback(() => [style && style], [style]);

  return (
    <RNPressable style={_style} {...otherProps}>
      {children}
    </RNPressable>
  );
}

export default Pressable;
```

So far, it accepts only two props:

- `children` that is used to add a label on the button (using like a `Text` component from React Native)
- `...otherProps` is used to pass down all the props to the underlying Pressable component.

In this case, since the wrapper component, you are creating will only be responsible for handling opacity, other important props like `onPress` are left to be handled where this wrapper component is used. I have to use the [Touch indicator on an iOS simulator](https://amanhimself.dev/blog/show-touch-indicator-on-ios-simulator/) to show that the button is pressed.

## Using the wrapper component

To use the wrapper component in its current state, import it:

```jsx
import { StyleSheet, Text, View } from 'react-native';

import Pressable from './Pressable';

export default function App() {
  return (
    <View style={styles.container}>
      <Pressable
        style={{ borderRadius: 4, backgroundColor: '#FF0063', padding: 8 }}
      >
        <Text style={styles.text}>Press me</Text>
      </Pressable>
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center'
  },
  text: {
    fontSize: 24,
    color: '#fff'
  }
});
```

Make sure to add some styles to the `Text` and the `Pressable` components.

## Running the example

Here is the output I get by running the code above. Notice that there is no visual feedback when I press the component on the app screen.

![ss1](https://i.imgur.com/XcLXQbn.gif)

## Adding opacity prop to the wrapper component

In some scenarios, you may want to add and use opacity as the feedback. For example, decrease the opacity to `0.5` when the button is being pressed.

You can extend the `styles` to accept a `pressed` argument. It is a boolean that tells whether the component is currently pressed or not. Using it, you can alter the value of the opacity property in styles.

In the wrapper component, add a new prop called `activeOpacity`. This prop accepts a number between `0` and `0.99`. It is used conditionally on the `opacity` property and will only be true when the component is pressed.

When the component is not in a pressed state, the opacity value is `1`.

```jsx
import React, { useCallback } from 'react';
import { Pressable as RNPressable } from 'react-native';

function Pressable({ children, style, activeOpacity, ...otherProps }) {
  const _style = useCallback(
    ({ pressed }) => [{ opacity: pressed ? activeOpacity : 1 }, style && style],
    [style]
  );

  return (
    <RNPressable style={_style} {...otherProps}>
      {children}
    </RNPressable>
  );
}

export default Pressable;
```

## Running the example with activeOpacity value

The below code snippet modifies the previous example to add an activeOpacity value of `0.5`:

```jsx
export default function App() {
  return (
    <View style={styles.container}>
      <Pressable
        style={{ borderRadius: 4, backgroundColor: '#FF0063', padding: 8 }}
        activeOpacity={0.5}
      >
        <Text style={styles.text}>Press me</Text>
      </Pressable>
    </View>
  );
}
```

The output after this step confirms that the opacity is changing as expected.

![ss2](https://i.imgur.com/LDyiXIu.gif)

## Conclusion

The [Pressable component](https://reactnative.dev/docs/pressable) has many props that can be used to write an extensive and customized wrapper that fulfills your app's requirements. It is preferred in the official React Native documentation and provides a future-proof way of handling touch-based events.


How to add opacity to a Pressable component in React Native

---
title: 'Open any folder from the Terminal app in a Finder on macOS'
date: '2022-07-21'
thumbnail: '/thumbnails/terminal.png'
slug: 'how-to-open-any-folder-from-terminal-in-finder-on-mac'
tag: 'tools'
canonicalUrl: 'https://amanhimself.dev/blog/how-to-open-any-folder-from-terminal-in-finder-on-mac/'
---

Often, I struggle or want to open the current directory I am working from the Terminal app to the Finder window on macOS.

I have been a macOS user for almost eight years now, and it never occurred to me that I couldn't open the current location from the Terminal app. Until recently, a frustration point led me to find the solution. Again, though, I am surprised by its simplicity.

To open the current working directory in the Finder window, use the following command:

```shell
open .
```

The `open` command opens a file or a folder. It exists on the macOS.

You can do more with this command. The `/` argument opens the root directory.

```shell
open /
```

A specific directory is also allowed:

```shell
open ~/Desktop
```

Using the option `R`, you can locate a specific file or folder in the Finder:

```shell
open -R /blog
```

## Opening files

There are more things that the `open` command can do. It can open files. For example, to open a markdown file in the default editor or IDE:

```shell
open ./blog/mm-yy/your-file-name.md
```

The above command opens the markdown file in the Xcode. You can pass the `-t` option to open in the file in a text editor.

```shell
open -t ./blog/mm-yy/your-file-name.md
```

## Opening URLs

It can do more than open files and folders. It can also open a URL in the default web browser set up on your machine:

```shell
open https://www.google.com
```

Use the option `a` to override the default web browser and specify a different one.

```shell
open -a Safari https://www.google.com
```


Open any folder from the Terminal app in a Finder on macOS

---
title: 'How to push local git tag to remote repository on GitHub'
date: '2022-06-26'
slug: 'push-local-git-tag-to-remote-repository-on-github'
thumbnail: '/thumbnails/git.png'
tag: 'git'
canonicalUrl: 'https://amanhimself.dev/blog/push-local-git-tag-to-remote-repository-on-github/'
---

After creating a git tag locally on a local project, I needed to push it on GitHub. The reason is that I'm hosting the project repository on GitHub.

## Pushing a tag to GitHub

Pushing a tag in git is similar to pushing a branch. The only difference is that it needs the specific git tag name.

```shell
git push -u origin <tag_name>
```

Here is an example. I had already created a new tag, `v0.1` on my local project. To push it to GitHub, I had to run:

```shell
gpush v0.1
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/amandeepmittal/[project-name].git
 * [new tag]         v0.1 -> v0.1
```

Note: I use the `gpush` alias for `git push -u origin`. Complete list of all the aliases I use for git, check this [dotfile](https://github.com/amandeepmittal/dotfiles/blob/master/.zshrc).

## Checking for if a tag is already pushed

To check if a tag is only available on local, run:

```shell
git push --tags --dry-run
```

The `--dry-run` option in the above command summarizes what will be included in the next commit.

If the output of the above command states `Everything up-to-date`, it means there are no tags available to push.

In case when the above command comes back with an output like the below, it means that the tag is available to push.

```shell
To https://github.com/amandeepmittal/[project-name].git
 * [new tag]         v0.1 -> v0.1
```


How to push local git tag to remote repository on GitHub

---
title: 'How to remove console statements from React Native apps'
slug: 'remove-console-log-from-react-native-apps-in-production'
date: '2022-06-19'
thumbnail: '/thumbnails/react.png'
tag: 'react-native'
canonicalUrl: 'https://amanhimself.dev/blog/remove-console-from-react-native-apps/'
---



For debugging purposes, I often use `console.log` statements in React Native and Expo applications.

A babel plugin called [babel-plugin-transform-remove-console](https://github.com/babel/minify/tree/master/packages/babel-plugin-transform-remove-console) takes care of removing any `console` statements from the code. This is a great plugin that I like to use, especially before releasing apps in production.

## How to use it

Install the plugin as a dev dependency in the project:

```shell
yarn add -D babel-plugin-transform-remove-console
```

Then, add it as a plugin under `env.production` in the `babel.config.js` file:

```js
module.exports = function () {
  return {
    // ... other project config such as presets and plugins
    env: {
      production: {
        plugins: ['transform-remove-console']
      }
    }
  };
};
```

This will remove any `console` statements from the code.

## Why does it works

React Native uses [Babel](https://babeljs.io/) as a tool to read and parse React and ES6 (or later) syntax into a specific version of JavaScript code that can run in an environment (that doesn't support newer ES6 or React syntax).

How to remove console statements from React Native apps

Getting Started with React Navigation v6 and TypeScript in React Native

---
title: 'Remove bottom border or shadow on header in React Navigation'
slug: 'remove-bottom-border-shadow-on-header-in-react-navigation'
date: '2022-06-05'
thumbnail: '/thumbnails/react-navigation.png'
tag: 'react-native'
canonicalUrl: 'https://amanhimself.dev/blog/remove-bottom-border-shadow-on-header-in-react-navigation/'
---



React Navigation is an amazing navigation library in React Native ecosystem. I have been a big fan because it allows a lot of customization when using different navigators (such as Stack, Tab, or Drawer).

One of the customizations that can be done is to remove the border at the bottom of the header. By default, the Stack and Tab Navigators in this library add a header on a screen. This header has a default bottom border or shadow.

Here is an example of a border on the header on iOS:

![ss1](https://i.imgur.com/PnxIHxT.png)

The orange arrows are used to highlight the shadow. Similarly, on Android, the width is thin and hard to notice.

![ss2](https://i.imgur.com/MoP6J0t.png)

To make it more visible, you can populate the `screenOptions` of the navigator as shown below:

```js
screenOptions={{
  headerStyle: {
    borderBottomWidth: 4,
  },
}}
```

Increasing the value of the property `borderBottomWidth` will make the border thicker.

![ss3](https://i.imgur.com/I7l8INR.png)

At times, the UI of the screen might not require a header border or shadow at all. In such cases, you can always customize the `screenOptions` by adding the property `headerShadowVisible` and setting it to `false`.

```js
screenOptions={{
  headerShadowVisible: false,
}}
```

You will get the desired output both on iOS and Android:

![ss4](https://i.imgur.com/bBQuIJJ.png)

![ss5](https://i.imgur.com/NId2zbQ.png)

## Conclusion

[React Navigation docs](https://reactnavigation.org/) are a great asset for learning more about the library and what customization options it provides.

Also, check out my other post on [how to remove the bottom tab bar border in React Navigation](https://amanhimself.dev/blog/react-navigation-remove-tab-bar-border/).

[Source code available at GitHub](https://github.com/amandeepmittal/react-native-examples/tree/main/remove-header-border-react-navigation)

Remove bottom border or shadow on header in React Navigation

---
title: 'How to remove AsyncStorage warning when using Firebase JS SDK with React Native'
slug: 'remove-asyncstorage-has-been-extracted-warning-using-firebase'
date: '2022-05-28'
thumbnail: '/thumbnails/firebase.png'
tag: 'firebase'
canonicalUrl: 'https://amanhimself.dev/blog/remove-asyncstorage-has-been-extracted-warning-using-firebase/'
---

The [Firebase JS SDK](https://github.com/firebase/firebase-js-sdk) is a library that provides a set of JavaScript APIs for interacting with Firebase services. I use it with some of the production React Native apps built with Expo, mainly for authentication, database, and storage. I also use it for an open-source template that I am currently maintaining called [expo-firebase-stater], which provides a head start when building a React Native app with Firebase.

For React Native apps, the Firebase SDK uses AsyncStorage under the hood to store an authentication session when an app restarts. It is one of the out-of-the-box features that Firebase provides that I like and use when implementing authentication in React Native apps using the Firebase Auth service.

## Why does the AsyncStorage warning occur

Typically, the Firebase Auth module is configured as shown below in a React Native app:

```js
import { initializeApp } from 'firebase/app';
import { getAuth } from 'firebase/auth';

const app = initializeApp(firebaseConfig);
const auth = getAuth(app);
```

Using this code snippet to initialize Firebase auth service in the app will cause the warning:

```shell
AsyncStorage has been extracted from the react-native core and will be removed in a future release ...
```

![ss1](https://i.imgur.com/pBiiXzY.png)

Firebase SDK uses the AsyncStorage module from the `react-native` core. From React Native versions `0.59` and up, the AsyncStorage module has been moved to its own package: `@react-native-async-storage/async-storage`.

[Here](https://github.com/firebase/firebase-js-sdk/blob/96ab56bac05ccaf506ed3a02ccad5ff7e01a07d0/packages/app/index.rn.ts#L27) is the line of code in Firebase JS SDK repo that imports AsyncStorage from `react-native` core:

![ss2](https://i.imgur.com/uWt9gRQ.jpg)

## Remove the AsyncStorage warning

To remove the AsyncStorage warning, start by installing the `@react-native-async-storage/async-storage` package:

```shell
# for Expo apps
expo install @react-native-async-storage/async-storage
```

Firebase SDK provides another method in its Auth module called `initializeAuth`. This method allows more control over the Auth instance from the `getAuth` method. In addition, it provides a way to define what persistence layer to use to store the authentication session using the method `getReactNativePersistence` and using which Dependency. Since we are using the Firebase auth service in a React Native app, we can use the React Native Dependency.

> Note: [Dependencies interface](https://firebase.google.com/docs/reference/js/auth.dependencies.md#dependencies_interface) in Firebase enables tree shaking. This means that a web app does not have to include all the dependencies that Firebase supports, such as Cordova or React Native.

Start by importing `initializeAuth` and `getReactNativePersistence` from `firebase/auth/react-native`. To initialize `auth`, pass an object as the second argument to the `initializeAuth` method. This object has a `persistence` key that takes the value of which persistence layer to use.

```js
import AsyncStorage from '@react-native-async-storage/async-storage';
import { initializeApp } from 'firebase/app';
import {
  initializeAuth,
  getReactNativePersistence
} from 'firebase/auth/react-native';

// add firebase config here

// initialize firebase app
const app = initializeApp(firebaseConfig);

// initialize auth
const auth = initializeAuth(app, {
  persistence: getReactNativePersistence(AsyncStorage)
});

export { auth };
```

Using the same strategy as the above code snippet should resolve the warning about AsyncStorage.


How to remove AsyncStorage warning when using Firebase JS SDK with React Native

---
title: 'Patterns and Anti-patterns in Node.js'
date: '2022-04-03'
slug: 'patterns-and-anti-patterns-in-nodejs'
thumbnail: '/thumbnails/node.png'
tag: 'nodejs'
canonicalUrl: 'https://blog.appsignal.com/2022/02/23/patterns-and-anti-patterns-in-nodejs.html/'
---

![cover_image](https://blog.appsignal.com/_next/image?url=%2Fimages%2Fblog%2F2022-02%2Fpatterns.png&w=2048&q=50)

> Originally posted at [AppSignal Blog](https://blog.appsignal.com/2022/02/23/patterns-and-anti-patterns-in-nodejs.html)

Node.js is a back-end JavaScript runtime built on Chrome's V8 engine that's asynchronous and event-driven by nature. It's relatively simple to create a REST API with Node.js and use frameworks like [Express.js](https://expressjs.com/). With this simplicity comes a lot of flexibility. However, you can get side-tracked on what patterns to follow when building scalable network-driven applications.

This article focuses on some of the patterns and practices to follow when building Node.js applications. You will learn about coding style, error handling, loggers, and testing.

Let's dive in!

## Node.js Coding Style and Best Practices

### const and let Keywords to Declare Variables

There are different ways to declare variables in JavaScript: the old school `var` and the more recent `let` and `const`.

`var` declares a function-scoped (when declared within a function) or globally-scoped variable (when declared outside a function).

`let` and `const` declare block-scoped variables.

`let` allows you to create variables whose value can change. When pointing to an object, it can be assigned to another object.

```js
let myInt = 3;
myInt = 6;
console.log(myInt); // 6
let myArray = [0, 1, 2, 3];
console.log(myArray); // [ 0, 1, 2, 3 ]
let myOtherArray = ['one', 'two', 'three'];
myArray = myOtherArray;
console.log(myArray); // [ 'one', 'two', 'three' ]
```

The `const` keyword can be a little confusing. It doesn't necessarily define a constant value, it defines a constant reference to a value. It creates a read-only reference to a value, but this doesn't mean the value it holds is immutable, just that it cannot be reassigned.

```js
const myInt = 3;
myInt = 6; // TypeError: Assignment to constant variable.
const myArray = [0, 1, 2, 3];
console.log(myArray); // [ 0, 1, 2, 3 ]
myArray[0] = 'eleven';
console.log(myArray); // [ 'eleven', 1, 2, 3 ]

let myOtherArray = ['one', 'two', 'three'];
myArray = myOtherArray; // TypeError: Assignment to constant variable
```

As shown above, if it holds a primitive, you cannot assign it another value. When it holds an object/array, you can alter the value of that object (its properties/elements), but you cannot assign it another object.

With the definitions down, let's look at why you should consider using `let` and `const` over `var`.

1. Duplicate variable declarations using `var` will not trigger an error.

With `var` you can declare a variable in the same scope as a similarly named variable. Because of this, you can unknowingly overwrite another variable's value.

```js
function thisFunction() {
  var x = 1;

  // In another part of the code, declare another variable x
  var x = 2;

  console.log(x); // 2
}

thisFunction();
```

Both `const` and `let` cannot be re-declared, so you cannot accidentally create a duplicate variable in the same scope.

```js
function thisFunction() {
  let x = 1;

  // In another part of the code, declare another variable x
  let x = 2;

  console.log(x);
}

thisFunction();
```

If you try to run the above code, you will get the following error:

```shell
SyntaxError: Identifier 'x' has already been declared
```

2. `var` allows you to read a variable that has not been declared.

When you try to access a `var` before it is declared, it will return `undefined`. This might cause bugs when you try to use a variable in your code that has not been declared. Tracking down the bug might be difficult since the code might cause no errors that will cause it to crash, but it might cause unexpected results when you use the `undefined`.

The following code will run just fine.

```js
console.log(bar); // undefined
var bar = 1;
```

With `let` and `const`, you won't be able to use a variable that has not been declared.

```js
console.log(foo); // ReferenceError
let foo = 2;
```

Trying to run the above will give the below error:

```shell
ReferenceError: Cannot access 'foo' before initialization
```

3. Because they are block-scoped, `let` and `const` make for more readable and straightforward code, that is less error-prone.
   With block-scoped variables, it is easier to read through code and track down the scope in which a variable operates. You just have to look at the inner-most block in which it has been declared to know its scope.

Look at the following code.

```js
let x = 5;

function thisFunction() {
  let x = 1;

  if (true) {
    let x = 2;
  }

  console.log(x); // 1
}

thisFunction();

console.log(x); // 5
```

Since `let x = 2;` is declared inside the block of the `if` statement, you know it only operates inside that block. As you can see, it doesn't affect similarly named variables outside the block. You can declare variables inside blocks without worrying that you might be re-declaring them.

When using `var`, it's not so straightforward.

```js
var x = 5;

function thisFunction() {
  var x = 1;

  if (true) {
    var x = 2;
  }

  console.log(x); // 2
}

thisFunction();

console.log(x); // 5
```

With `var`, you have to be more careful with variables.

In the above, we declare a variable `var x = 2;` inside the `if` statement. The scope of `x` is the entire function `thisFunction()`. Since there is a similarly named variable in the function, we re-declared `x`, and when we later use the function's `x`, it has the value `2`. So you need to be aware of the variables in scope, so as not to accidentally overwrite them.

### Proper Naming Conventions

It's important to follow a naming convention when naming constants, variables, classes, and functions in an app. This helps you visually differentiate between local variables, global variables, functions, classes, etc., and maintain a consistent style throughout your codebase.

For naming local variables and functions, use lowerCamelCase.

```js
const myFunction() {
  let someVariable;
}
```

Even if you define variables using the `const` keyword within the scope of a function, lowerCamelCase is preferred.

```js
const myFunction() {
  const someVariable = "That holds a string value";
}
```

Variables can also be defined by a `const` keyword in a specific use case. If you intend to declare a variable whose value (or nested values, in the case of declaring an object) is not going to change throughout the lifecycle of a codebase, use UPPER_SNAKE_CASE with the `const` keyword.

```js
const ANOTHER_VAR = 3;
```

Define classes in Node.js applications with UpperCamelCase:

```js
class MyClass() {
  // ...
}
```

Following these naming conventions will help you write more readable code. Naming your functions is vital, especially when you are about to profile a Node.js project. Profiling makes it simpler to understand what function to look for when checking a memory snapshot. However, if you use anonymous functions, profiling can make it challenging to debug production issues.

### ESLint and Style Guides

Instead of overthinking a project's coding style, use a linting tool like [ESLint](https://eslint.org/). Over the years, it has become the JavaScript ecosystem's standard for fixing code styles automatically. ESLint checks for possible code errors, fixes code styles such as spacing issues, avoids anti-patterns and small errors, and keeps project code uniform. Using ESLint with a tool like [Prettier](https://prettier.io/) can help you fix formatting issues as well.

By default, ESLint contains standard rules for vanilla JavaScript. It has a plugin system specific to the framework. For Node.js, you can use plugins like eslint-plugin-node and eslint-plugin-node-security.

It is much easier to understand a large project when its code is written in a consistent style. This is where style guides come in handy. Using a style guide enhances a team's productivity and avoids arguments about the best style guide for Node.js projects. In addition, you can opt-in to already existing style guides created at companies like [Google](https://github.com/google/eslint-config-google) and [Airbnb](https://github.com/airbnb/javascript) that have been tested with time.

## Error Handling in Node.js

You can handle errors using `async/await` syntax and the built-in error object in Node.js. Let's take a look at both.

### async/await Syntax to Catch Errors

When Node.js first came out, handling asynchronous code meant using callbacks. From my experience, it doesn't take too long for nested callbacks to get out of hand. This is known as 'callback hell', and here is a typical example:

```js
function getData(err, function(err, res) {
  if(err !== null) {
    function(valueA, function(err, res) {
      if(err !== null) {
        function(valueB, function(err, res) {
          // it continues
        }
      }
    })
  }
})
```

The example above is quite ergonomic. In a real scenario, there will be many more lines of code in each function's scope. This is considered an anti-pattern: handling the callback style of errors gets more awkward and only gets more un-maintainable with more nested functions.

You can avoid nested callbacks or callback hell by using ES6 `async/await` syntax (completely supported by Node.js version 8 and onwards). `async/await` is a way to deal with asynchronous code. It provides a much more compact way of writing code and familiar code syntax. To handle errors, you can use `try/catch` blocks along with `async/await` syntax.

If we use `async/await`, we can rewrite the previous example like this:

```js
async function getData(err, res) {
  try {
    let resA = await functionA(res);
    let resB = await functionB(resA);

    return resB;
  } catch (err) {
    logger.error(err);
  }
}
```

### Built-in Node.js Error Object

Errors are impossible to avoid. However, in many cases you'll want to handle errors such as rejected promises and thrown exceptions.

To avoid complications in error-handling, use the built-in error object in Node.js. It helps you maintain uniformity and prevent loss of information. You can also reap the advantages of finding information with StackTrace.

As an example, throw a string as shown below:

```js
if (!data) {
  throw 'There is no data';
}
```

This lacks any stack trace information and is an anti-pattern.

Instead, use the built-in Error object:

```js
if (!data) {
  throw new Error('There is no data');
}
```

## Loggers for Your Node.js Project

There's no denying it - we've all used `console` statements at times. They can be good for quickly debugging something or printing a standard output. But the console lacks proper configuration options for production-grade applications.

It is also crucial for a logger to be high-performant in identifying errors and possible issues. A slow logging library might harm your application's runtime performance.

A typical logger lets you use correct log levels such as fatal, warn, info, error, debug, and trace. These levels help to identify and distinguish between different critical events. A logger will also help provide contextual information in a JSON object, with timestamped log lines for you to determine when the log entry occurred. The logging format should be readable by human beings.

A good logging library provides features that make it easier to centralize and format logs. In the Node.js ecosystem, the following are some of the options available:

- [Winston](https://github.com/winstonjs/winston): A popular logging library that is easily configurable.
- [Bunyan](https://github.com/trentm/node-bunyan): Another popular logging library that outputs in JSON by default.
- [Log4js](https://github.com/log4js-node/log4js-node): A logger for the Express framework that supports colored console logging out of the box.
- [Pino](https://github.com/pinojs/pino): A logger that is focused on performance. It is considered to be faster than its alternatives.

An example of configuring Pino:

```js
const app = require('express')();
const pino = require('pino-http')();

app.use(pino);

app.get('/', function (req, res) {
  req.log.info('something');
  res.send('hello world');
});

app.listen(3000);
```

Pino also supports [various Web frameworks in the Node.js ecosystem](https://github.com/pinojs/pino/blob/HEAD/docs/web.md#express), such as Fastify, Express, Hapi, Koa, and Nest.

## Writing Tests in Node.js

If you work on a big application, you'll make continuous changes to the app's source code. By writing tests, you can avoid breaking existing features when pushing a new change. Failing tests will also help you determine where to make changes in specific sections of your code.

### Write API Tests

In a Node.js application, writing API tests is a good start. They provide more coverage than unit testing. You can use frameworks like [Supertest](https://github.com/visionmedia/supertest), [Jest](https://jestjs.io/), or any other library that provides a high-level abstraction for testing APIs.

Consider the example below. It is a simple Express app that serves one route:

```js
const express = require('express');
const bodyParser = require('body-parser');

const app = express();

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// Other middlewares...

app.get('/', (req, res, next) => {
  res.json({ hello: 'Hello World' });
});

module.exports = app;
```

Here's appropriate way to write this using Supertest:

```js
const request = require('supertest');
const app = require('./index');

describe('hello test', () => {
  it('/ should return a response', async () => {
    const res = await request(app).get('/');
    expect(res.statusCode).toEqual(200);
    expect(res.body).toEqual({ hello: 'Hello World' });
  });
});
```

### Write Clear Test Names

A test name should be descriptive and self-explanatory for other people working on your team and include what is being tested, the scenario, and expected result.

### Inspect Outdated Packages

You can check for outdated packages with commands like `npm outdated` or use a package like `npm-check`. This will prevent build fails related to outdated packages.

### Inspect for Vulnerable Dependencies

A package can have vulnerabilities. Use community-based tools such as [npm audit](https://docs.npmjs.com/cli/audit) or commercial tools like [snyk](https://snyk.io/) to discover vulnerabilities. If you don't use these tools, your only alternative is to keep up with tech communities online.

## Wrap Up: Write Better Code for Your Node.js Apps

In this article, we covered practices and patterns to help you avoid anti-patterns and write better code for your Node.js applications.

We looked at some key principles around coding style, error handling, loggers, and testing. Some of the practices we discussed are more general - like checking for outdated packages or vulnerable dependencies. Others - such as using a performant logging library using ESLint and style guides - will help you maintain a consistent way of writing code, especially when working on large projects.

Happy coding!


Patterns and Anti-patterns in Node.js

---
title: 'How to show Touch indicator on iOS simulator'
date: '2022-04-03'
slug: 'show-touch-indicator-on-ios-simulator'
thumbnail: '/thumbnails/xcode.png'
tag: 'xcode'
canonicalUrl: 'https://amanhimself.dev/blog/show-touch-indicator-on-ios-simulator/'
---

Sometimes it is necessary to highlight a single touch event on the iOS simulator's screen and show the tap that registers it. For example, this is useful when recording a video or a [gif](https://en.wikipedia.org/wiki/GIF) using the simulator.

The iOS simulator comes with a pre-configured list of settings, including to display the touch indicator. However, sometimes, it is hard to find them.

## Enable Touch Indicator on iOS simulator

To enable the touch indicator, open the terminal window and run the following command:

```shell
defaults write com.apple.iphonesimulator ShowSingleTouches 1
```

It accepts a boolean value of `1`.

After running the command, if the iOS simulator is already running, close and restart it.

To test it out, open the simulator and tap on the screen.

![ss1](https://i.imgur.com/h31kDO1.gif)

## Disable Touch Indicator on iOS simulator

To disable the touch indicator from the terminal window, run the following command to change the boolean value to `0`:

```shell
defaults write com.apple.iphonesimulator ShowSingleTouches 0
```


Hey, I'm Aman

I'm a software developer and a technical writer. I love working with open source technologies and writing about what I learn.

I've been writing online since 2017, mostly on web and mobile development. I've written over 150 articles for more than 30 publications and organizations across the internet. Hence, I started this blog to share my software development journey.

Currently, working at Expo. Previously, I've worked as Developer Advocate, and Senior Content Developer with companies like Draftbit, Vercel and Crowdbotics.

Latest Posts

Open Source Projects I've Worked on

Countries I've Visited