Skip to content

Instantly share code, notes, and snippets.

@nicolasdao

nicolasdao/typescript_guide.md

Last active May 2, 2024 02:15
Show Gist options
  • Save nicolasdao/9c8fb6a915466749492213e8cdd9c879 to your computer and use it in GitHub Desktop.
Save nicolasdao/9c8fb6a915466749492213e8cdd9c879 to your computer and use it in GitHub Desktop.
Download ZIP
Typescript guide. Keywords: typescript type script ts
Raw
typescript_guide.md

TYPESCRIPT GUIDE

Table of contents

Compiler

Disabling it inline

// @ts-ignore-start
const data = await resp.somethingThatMakesTSshitItself()
// @ts-ignore-end

Defining types

On-the-fly definitions

Defining one required id parameter and one optional name parameter:

const myFunc = (id:number, name?:string) => {
	console.log({
		id,
		name
	})
}

Defining an object with one required id parameter and one optional name parameter:

const myFunc = ({ id name }:{ id:number, name?:string }) => {
	console.log({
		id,
		name
	})
}

Using interfaces

Defining an object with one required id parameter and one optional name parameter:

interface TaskPaneProps {
	id: number,
	name?: string
}

const myFunc = (props: TaskPaneProps) => {
	console.log(props)
}

Defining an object with additional unknown properties:

interface TaskPaneProps extends Record<number, any> {
	id: number,
	name?: string
}

const myFunc = (props: TaskPaneProps) => {
	console.log(props)
}

console.log('THIS VALID:')
myFunc({ id:1, hello:'world' })

NOTICE: Record only supports 2 types. Pick one the type used in the interface, then any.

Defining types for non-typescript packages

Just add a whatever.d.ts file in your project root. In that file, explicitly define the misisng types:

declare module 'puffy-core/error'
declare module 'puffy-core/collection'

On the fly typing

const myVar:string = 'Hello'
const myNullableVar:string|null = 'Hello'
const myIdontGiveAfuckAboutTypeVar:any|null|undefined = 'Hello'

Troubleshooting

Issues checking service aborted - probably out of memory. Check the memoryLimit option...

This could be due to a misconfiguration in the tsconfig.json file. Check the the include property does not contain something outrageous like including the entire node_modules folder.

Annexes

Why Typescript sucks balls

Regulation vs Deregulation

In my journey to articulate my disdain for Typescript, I concluded that there were no undisputable arguments not to use it. In my view, this debate is a conflict of values similar to the opposition between free-market ideologists and Government regulation proponents.

Native Javascript imposes very few restrictions on how you write code. There is pretty much no regulation, and, in the wrong hands, this language can(will) leads to frequent crisis. Typescript, on the other hand, is the tool of the regulator. The regulator does not trust the market and needs to write strict policies to encourage and deprecate specific behaviours. In Typescript, those tools are types, interfaces, public/private/protected/abstract/static classes and so on. If you feel that regulating your code is a critical aspect to guarantee the success of your project, then Typescript is the tool you've been waiting for. If you consider that any regulation concerns is incidental complexity that results in not starting a project in the first place, then avoid Typescript like the plague.

This conflict of values produces no winners. Instead, it is part of a healthy debate between good sports, which, hopefully, proves we can share our disagreements in a civilized fashion.

Developing in native Javascript is faster than developing in Typescript

The reasons are simple:

  • Less tooling and less set up.
  • Easier to debug. You will eventually loose so much time trying to debug a Typescript project in production.
  • Less boilerplate to get shit done. Typescript comes from a OO mindset

Javascript is amazing and if you feel you need more, it simply means you don't know enough about it

Types and type-checking are overated

Dynamic typing is amazing, type inspection sucks balls

This is powerful:

const a = { name: 'Nic' }
a.age = 38

// or
const fieldName = 'motorbike'
const b = { [fieldName]: 'Harley' }
console.log(b.motorbike)

Data-wrangling is 10x easier with dynamic types

Counter-arguments from people who love TypeScript

Final thoughts

I feel that the biggest issue with Typescript is its root in the OO mindset. Using Typescript felt like going back to C# (where I started). When I left C# after almost 10 years of professional of enterprise practice, I had become sick of the excess code to create interfaces, abstract classes and enterprise design patterns best practices. The code and knowledge required to get shit done was such a deterrent to start anything new, which is why Microsoft, or the almost any other enterprise stack, put a lot of efforts in creating over-engineering tools (Visual Studio, Eclipse, IntelliJ back in the days) to provide with templates, and auto-complete, ... Those tools are regarded as the pinacle of innovation and you keep running in your hamster wheel to stay up-to-date with them. The truth is, you need those tools to help you because the underlying stack is flawed by design. When I started coding in Pythin then Ruby, it became so obvious. It was so easy to start any project, small or big with minumum tooling and the most minimalist code editor. Then, when I discovered NodeJS, the love story was immediate. My productivity in terms of new personal project went though the roof, and guess what? I did not need intelli-sense, auto-complete, or type-checking. I definitely did not miss the lengthy build time. The interval between ideation to creation was tremedously shortened. That gain of speed yield incommensurable benefits, one of which I feel is the biggest one: An positive and excited mindset when it comes to start something new. When you are excited to start something new because it is going to be so easy, then you start an unstoppable and addictive force to be productive and learn more and faster. That's when I observe this psoitive change withing myself that I understood the power of simplicity and minimalism, and today, those two characteristic have become my engineering and life mantra. As an engineer, any piece of technology that slows me down or make me think too much (related to the Don't Make Me Think approach from Steve Krug) are fat that must be lost. IMHO, Typescript is pure excess fat.

I started my software engineering career using C#. It took me just under 10 years before leaving the .NET stack behind. During that transition period, I dabbled with Python, then started to do more DevOps with Ruby. NodeJS had become stable and was gaining a lot of momentum. Since I had fallen in love with dynamic language thanks to Python and Ruby, I decided to give NodeJS a shot. The love story started almost immediately. The essential bits of te NodeJS stack that won me were:

  • So easy to debug your dependencies. The fact that all dependencies were installed locally in your project under the node_modules is such a massive benefit. If something breaks, you simply open that folder, located the package where the error originiated and start modifying code or add logs. This approach is clear. You know where the error is originating from, and you also know how to dig deeper. In C#, you're dealing with binaries, and some of them are installed in the GAC. Good luck to find where those packages are, and forget about hacking the code. Python and Ruby package management was still light years ahead of .NET, but still not as clean and clear as NPM.
  • NPM rocks! NPM is full of little treasures. Forget about Gulp, or Grunt. NPM scripts should cover 95% of your use cases.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment