labs42io / clean-code-typescript Goto Github PK

Best practices for writing modules with TypeScript

• import
• export (to use or not to use export default)

etc.

Hi,

Could we add the spread operator to this?

function createMenu(config: MenuConfig) {
  const menuConfig = {
    title: 'Foo',
    body: 'Bar',
    buttonText: 'Baz',
    cancellable: true,
    ...config,
  };

  // ...
}

Thanks for your work

Hi!

Thanks for your great guide to clean coding with TypeScript! I have created a web "e-book" version of your guide with the HonKit application.

You can check out the web version here: https://tderflinger.github.io/clean-code-typescript-ebook/ and the source code here: https://github.com/tderflinger/clean-code-typescript-ebook

So I wanted to ask if you could add a link to my website. Alternatively, I might create a PR with my changes so you can integrate the version with HonKit into your project. What do you think about that?

Best regards,
-Thomas

Section: Variables:

• Provide motivation and samples of when to use TypeScript enums.

Should we cover generics?

I saw in many interviews people that doesn't know that we can access Type['attribute'] like this. In some cases it's good because typescript will show you where code will break. For example

given we have a type Person

type Person = {
  id: string;
  name: string;
}

many people create specific functions like this

const getPersonName = (id: string) => {}

besides if you change the attribute's type or name it'll not break anything and you'll suffer to find every place to update, but when we use like this below

const getPersonName = (id: Person['id']) => {}

typescript will tell you where code will break.

There's another cases for whose use the entire type for function parameter instead of use Pick/Omit/etc.

Provide good samples and motivation to use iterators/generators in Functions section.

hi
Could I translate this to Persian language?
I want to trans

In the example of "Function arguments (2 or fewer ideally)"
There is a talk about destrcuting, which to what I know is:

const object = {a: 1, b: 2};
const {a, b} = object; // This is destrcuting

Now what the code there does is

function createMenu(options: { title: string, body: string, buttonText: string, cancellable: boolean }) {
  // ...
}

createMenu({
  title: 'Foo',
  body: 'Bar',
  buttonText: 'Baz',
  cancellable: true
});

I can't find the destructing here (I don't think declaring option type should be considered as destructing.
In the "Set default objects with Object.assign or destructuring" the last example actually does use destructing unlike in this example.
Maybe the paragraph of "Function arguments" should be changed? Or am I missing something here?

Instead of "It will still be safe in your version history if you still need it.", I think it should be "It will still be saved in your version history if you still need it."

although tslint is introduced in Formatting, since most tslint rules do not override interface-over-type-literal and are true, contents of type vs interface will error .
(confirming, only TSLint Clean Code was false)

also issues, it may be deleted from tslint: recommended in future, but it has not disappeared at moment.

Important thing is that if you follow the rules of tslint, will most likely result in an error.

need to set interface-over-type-literal to false as a workaround, should prompt for a trade-off with quality.

should I add this as a supplement to type vs interface?

Hi! Thank you for this repo, it is really useful :)

I would like to add a complete example of the use of clean code and clean architecture concepts (by creating for example the backend for a classic note-taking app).

Do you think that could be interesting for the community?

I don't understand this rule in the aspect of why would you add a getter / setter for a simple property with not logic?
The example demonstrates exactly how you can always take a regular property and refactor it easily only within the class to use a getter / setter without editing any of the usage of it (getters and setters act like regular properties outside of the class).
So with this in mind, why would you add getter / setter in advance for simple properties without any logic?

Add more samples and description to Objects and Data Structures about builtin types in TypeScript, like the Partial, ReadonlyArray etc.

Help needed to add translations.

Provide samples and explanation when/how to use // TODO comments (in Comments section).

want you to incorporate features that you think are personally wonderful entering from typescript 3.4

https://github.com/labs42io/clean-code-typescript#avoid-side-effects-part-1

The const definition does not block rewriting of the contents of object, but you can handle immutable objects by using as const.
(It can be experienced with typescript 3.4.0-dev)

microsoft/TypeScript#29510

Proposal to add a section with examples about cross-cutting concerns:

• decorators
• Proxy
• Reflect

`type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean };

function createMenu({ title = 'Foo', body = 'Bar', buttonText = 'Baz', cancellable = true }: MenuConfig) {
// ...
}

createMenu({ body: 'Bar' });`

Crossing the example given in "Set default objects with Object.assign or destructuring" with one of the first rules:
"Function arguments (2 or fewer ideally)
Limiting the number of function parameters is incredibly important because it makes testing your function easier. Having more than three leads to a combinatorial explosion where you have to test tons of different cases with each separate argument."

Isn't this example actually crossing the line of having more than 3 arguments? Logically I feel like the destructing example is with object with more than 3 properties is the same as giving the function more than 3 arguments for the exact same reason specified in this rule. Am I wrong to think this way?

We should change the references from TSLint to ESLint as TSLint has been deprecated as of 2019.

See https://palantir.github.io/tslint:

⚠️ TSLint is deprecated.

See this issue for more details: Roadmap: TSLint → ESLint. If you're interested in helping with the TSLint/ESLint migration, please check out our OSS Fellowship program.

Do not add unneeded context
https://github.com/labs42io/clean-code-typescript#dont-add-unneeded-context

argments is not this., is not it a car ?
(sample gives an error)

type Car = {
  make: string;
  model: string;
  color: string;
}

function print(car: Car): void {
  console.log(`${car.make} ${car.model} (${car.color})`);
}