Anthony Manning-Franklin Yep it sure supported autocomplete, my bad @@ and I also found out about how enum wasn't that good in TypeScript so I have fully switched to Union Type now. Ah yes thank you for these awesome blog plots. I have implemented some in my project. I also ask questions in some of your article's comment section. Can you please check them :")

Very good design pattern to handle business logic exception. Yeah, those outcomes/exceptions/errors are from business logic, they are defined by developers. But what about, errors that are thrown from 3rd-party packages? Example: import {readSync} from 'fs' ... const json = await readSync(pathToFile) and somehow there is an exception throw from readSync via many reason (file not found, file corruption, some process delete it, ...). How will you handle this?

This could be applied to any TypeScript project right. I'm writing a VSCode Extension using TypeScript so I learning some of the best folder structures.

This is also bugging my mind since using enum means you don't need to remember the exact literal string like "PENDING_VERIFICATION". You just define enum AccountStatus { PendingVerification = 'PENDING_VERIFICATION' ; Active = 'ACTIVE' , Locked = 'LOCKED' } and use VSCode autocomplete feature. E.g. AccountStatus.Pend- => AccountStatus.PendingVerification

Omg, this is the blog I was searching for a long time. I was trying to do OOP in TypeScript and sometimes I felt like I didn't harness the power of FP. And great job in that Partially Applied Controller that encapsulate impure + pure function and separate function logic into 3 parts: Data Retrieval (In-memory, File, DB, Remote API, ...) Business Logic Error/Exception Handler for both Data Retrieval and Business Logic (using Discriminated Union Type or Either Design Pattern). I'm currently learning Either Design Pattern. These knowledge will definitely be put in use in my VSCode Extension that used TypeScript. This is also the project for my graduation thesis.