2022-11-03
1820
#typescript
Paul Cowan
139904
Nov 3, 2022 ⋅ 6 min read

Write fewer tests by creating better TypeScript types

Paul Cowan Contract software developer.

Recent posts:

Handling File Uploads In Next.js Using UploadThing

Handling file uploads in Next.js using UploadThing

Manage file uploads in your Next.js app using UploadThing, a file upload tool to be used in full-stack TypeScript applications.

Jude Miracle
Jun 21, 2024 ⋅ 15 min read
Exploring Advanced Support For Vite 5 In Storybook 8

Exploring advanced support for Vite 5 in Storybook 8

Explore the latest updates in Storybook 8, focusing on its improved support for Vite 5 as a build tool.

Will Soares
Jun 20, 2024 ⋅ 5 min read
Using Next Js With React Suspense To Create A Loading Component

Using Next.js with Suspense to create a loading component

Next.js 13 introduced some new features like support for Suspense, a React feature that lets you delay displaying a component until the children have finished loading.

Suraj Vishwakarma
Jun 19, 2024 ⋅ 9 min read
Exploring Angular 18's Redirectcommand Class And Let Block

Exploring Angular 18’s RedirectCommand class and @let block

Angular’s latest update brings greater control over redirects and the ability to define and assign variables within the template.

Lewis Cianci
Jun 19, 2024 ⋅ 6 min read
View all posts

One Reply to "Write fewer tests by creating better TypeScript types"

  1. Nice article I find good typechecking very helpful. However, having more code does not always mean that you have to more problems.

    Shared code that is to tightly coupled creates huge issues with business domain changes and refactoring.

    A properly decoupled system using MVVM that has proper Domain Drive Design and isolated business flows will help prevent unintended sideeffects as business needs change.

    Which may result in small portions of repeated code.

    This is prefered because business logic may change in a business flow and should not be shared across an entire application.

    DRY does not overide Single Resposibility and the scope you choose for SRP is important and should not bleed into different business flows with out a concrete reason.

    In MVVM this occurs fairly often at the view layer and even in the view-model.

    Each of the model, view and view-model layers can be tested and developed independently which enable paralalyzed development, AB testing, and easy refactoring.

    Tight type checking actually makes it more challenging to refactor and this is the reason kotlin was born.
    Kotlins loose type checking enable faster refactoring and iteration by enabling you to gaurd code blocks and domains with typechecks.

Leave a Reply