TypeScript es una extensión fácil de aprender de JavaScript. Es fácil escribir programas que se ejecutan y hacen algo. Sin embargo, es difícil tener en cuenta todos los casos de uso y escribir código TypeScript robusto.

En este artículo, veremos las prácticas recomendadas a seguir al escribir código con TypeScript, incluida la no escribir interfaces vacías.

Además, debemos usar las promesas de una manera útil.

El tipo tampoco debe usarse.any

Además, las clases no se deben usar como espacios de nombres en TypeScript.

Sin declaraciones de interfaz vacía

Las interfaces vacías no son muy útiles. Por lo tanto, probablemente no los queremos en nuestro código.

Así que en lugar de escribir:

interface Foo {}

interface Baz extends Foo {}

Escribimos:

interface Foo {
  name: string;
}

interface Baz extends Foo, Bar {}

La extensión de 2 tipos heredan miembros de ambos tipos, por lo que puede ser útil.

No use el tipo any

El tipo permite asignar cualquier cosa a una variable en TypeScript.any

Por lo tanto, el uso del tipo omitirá la comprobación de tipos para cualquier cosa con ese tipo.any

Para maximizar la utilidad del compilador TypeScript, debemos agregar algunos tipos.

Así que en lugar de escribir:

const foo: any = 'bar';

Podemos escribir:

const foo: string = 'bar';

Del mismo modo, para matrices, si tenemos:

const arr: any[] = [1, 2];

Debemos escribir:

const arr: number[] = [1, 2];

en lugar de.

Para los parámetros, escribimos:

function greet(names: Array<string>): string {}

En lugar de:

function greet(names: Array<any>): string {}

We can make our types dynamic with union types, intersection types, and index signatures.

These are much better choices than using .any

No Extra Non-Null Assertion

We shouldn’t have non-null assertion that doesn’t add any extra value in our code.

For instance, if we have:

const bar = foo!!!.bar;

or:

function baz(bar?: { n: number }) {
  return bar!?.n;
}

Then the or there’s a nullable operator which cancels out the non-null operator or they’re redundant.!

Instead, we should make our non-null operator useful by writing:

const bar = foo!.bar;

Don’t Use Classes as Namespaces

Classes shouldn’t be used as namespaces.

In TypeScript, we can put code other than classes at the top-level, so we can just do that instead of wrapping them in a class.

For instance, instead of writing:

class Foo {
  constructor() {
    foo();
  }
}

or:

class AllStatic {
  static num = 42;
  static greet() {
    console.log('Hello');
  }
}

We can write:

class Foo {
  constructor() {
    foo();
  }
  
  bar(){}
}

or:

class Bar {
  num = 42;
  greet() {
    console.log('Hello');
  }
}

We should have some instance methods or fields so that we actually need to create a class.

If we only have static variables, then we should create an object literal.

If we have an empty class or a class with only a constructor, then we don’t need the class.

Requerir valores similares a promesas para ser manejados correctamente

Debemos manejar los valores similares a las promesas correctamente.

Así que si tenemos una promesa en nuestro código, debemos usar en una función y bloquear para detectar errores.awaitasynccatch

O invocamos una promesa, entonces debemos llamar y / o en ella para detectar errores.thencatchfinally

Por ejemplo, en lugar de escribir:

const promise = new Promise((resolve, reject) => resolve('foo'));

const foo = async() => {
  return 'value';
}

Promise.reject('error').catch();

Promise.reject('error').finally();

Debemos escribir:

const promise = new Promise((resolve, reject) => resolve('value'));
await promise;

const foo = async () => {
  return 'value';
}
foo().then(
  () => {},
  () => {},
);

Promise.reject('error').catch(() => {});

Promise.reject('error').finally(() => {});

Si nuestra promesa devuelve un valor resolviendo o rechazando, entonces debemos manejarlos.

De lo contrario, es posible que no necesitemos la promesa de estar presentes en nuestro código.

Conclusión

Debemos usar las promesas de una manera útil en nuestro código. De lo contrario, deberíamos eliminarlos.

Las clases no se deben usar como espacios de nombres, ya que podemos colocar código en el nivel superior.

Por último, no deberíamos tener interfaces vacías en nuestro código.

TypeScript – Buenas practicas en Interfaces, clases