"Split or condition in if" refactoring in TypeScript
Tags: refactoring, beginners, webdev, programming
Published: 2023-01-30 18:45:16

---
title: '"Split or condition in if" refactoring in TypeScript'
published: true
description: 
tags: 
- refactoring 
- beginners
- webdev
- programming
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/02y45udunpdhm46h8rtw.jpg
canonical_url: https://codesai.com/posts/2022/12/split-or-condition-in-ts
---

In a [previous post](https://dev.to/trikitrok/split-or-condition-in-if-refactoring-5bno) we documented the **Split or condition in if** refactoring. This refactoring works fine for most languages. Unfortunately, it may occasionally present some problems in TypeScript because of how its compiler works.

After applying the **Split or condition in if** refactoring, the resulting code will contain duplication, and there may be obsolete if statements containing either unreachable code or code that is always executed, that we will clean. 

If the resulting code contains any if statement whose boolean condition always evaluates to false, the TypeScript compiler will emit a [TS2367 error](https://typescript.tv/errors/#TS2367), even though the code is functionally correct. We show an example of this problem in the following figure.

![Image Compiler error when a boolean expression always evaluates to false.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3l7g92rkg7zx4m6ie7ja.png "Compiler error when a boolean expression always evaluates to false.")
<figcaption><strong>Compiler error when a boolean expression always evaluates to false.</strong></figcaption>

In these cases, the code would not compile again, and as a consequence, the test won’t pass until we remove all the boolean conditions that always evaluate to false or indicate the compiler to ignore them using `@ts-ignore` or `@ts-expect-error`. This might be ok if there are only a few *TS2367 errors*. If not, cleaning those expressions will take too much time editing without having any feedback from the tests.

<h3>Revised mechanics for TypeScript.</h3>

[From TypeScript 3.7 onward](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#-ts-nocheck-in-typescript-files), we can add the `@ts-nocheck` rule to the top of TypeScript files to disable semantic checks (before that version, `@ts-nocheck` only worked for JavaScript files).

Using TypeScript’s `@ts-nocheck` rule will help us getting a shorter feedback cycle again, when cleaning redundant code resulting from applying the **Split or condition in if** refactoring that contains *TS2367 errors*. 

We only need to slightly modify the original **Split or condition in if** refactoring mechanics:

<ol>
    <li> 
      Add  the <code class="language-plaintext highlighter-rouge"> @ts-nocheck</code> rule to the top of TypeScript files to disable semantic checks.</li>
    <li>
      Apply <a href="https://dev.to/trikitrok/split-or-condition-in-if-refactoring-5bno/#mechanics">the original <b>Split or condition in if</b> refactoring
            </a>.
    </li>
    <li>
      Remove obsolete if statements in small steps while being able to get feedback from the tests at any time. 
    </li>
    <li> 
      Remove the  <code class="language-plaintext highlighter-rouge"> @ts-nocheck</code> rule to enable semantic checks again.
    </li>
</ol>

In the following video, we show an example of how using `@ts-nocheck` allows us to be able to keep refactoring the code in small steps after applying the **Split or condition in if** refactoring.

{% embed https://www.youtube.com/watch?v=0DWCSGSAGW8 %}

<h3>Conclusion.</h3>

We described a problem that TypeScript developers will find when the code resulting after applying the **Split or condition in if** refactoring contains any boolean condition that always evaluates to false which will produce *TS2367 errors*, and we provided a way to fix it. Following revised **Split or condition in if** refactoring mechanics that we proposed, you will be able to keep refactoring in small steps to remove unreachable code left after applying the **Split or condition in if** refactoring even when there are *TS2367 errors*. 

We hope this revision of the **Split or condition in if** refactoring would be useful for TypeScript developers.

<h2>Acknowledgements.</h2>

I’d like to thank [Fran Reyes](https://twitter.com/fran_reyes) for recording the **Split or condition in if** refactoring video in this post, and for giving me feedback on the contents of this post.

I’d also like to thank [Yuliya Kota](https://www.pexels.com/@yuliya-kota-2099022/) for her photo.

## References

### Articles

- ["Split or condition in if" refactoring](https://dev.to/trikitrok/split-or-condition-in-if-refactoring-5bno), [Manuel Rivero](https://garajeando.blogspot.com/)

- [TypeScript errors and how to fix them](https://typescript.tv/errors/)

- [TypeScript 3.7 Release Notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html)

Photo by [Yuliya Kota](https://www.pexels.com/@yuliya-kota-2099022/).