Urara-Blog/node_modules/.pnpm-store/v3/files/5e/06dd7a5e433aa53f1a05e0d5702b219592b6976418bd8d6ab953a6ceee3295cb96fa8961e5c61e2aa0b681c6bee639d75b152953c6c687dfad8b25398a1d51
2022-08-14 01:14:53 +08:00

114 lines
3.3 KiB
Text

---
description: 'Enforce that literals on classes are exposed in a consistent style.'
---
> 🛑 This file is source code, not the primary documentation location! 🛑
>
> See **https://typescript-eslint.io/rules/class-literal-property-style** for documentation.
When writing TypeScript applications, it's typically safe to store literal values on classes using fields with the `readonly` modifier to prevent them from being reassigned.
When writing TypeScript libraries that could be used by JavaScript users however, it's typically safer to expose these literals using `getter`s, since the `readonly` modifier is enforced at compile type.
## Rule Details
This rule aims to ensure that literals exposed by classes are done so consistently, in one of the two style described above.
By default this rule prefers the `fields` style as it means JS doesn't have to setup & teardown a function closure.
:::note
This rule only checks for constant _literal_ values (string, template string, number, bigint, boolean, regexp, null). It does not check objects or arrays, because a readonly field behaves differently to a getter in those cases. It also does not check functions, as it is a common pattern to use readonly fields with arrow function values as auto-bound methods.
This is because these types can be mutated and carry with them more complex implications about their usage.
:::
### The `fields` style
This style checks for any getter methods that return literal values, and requires them to be defined using fields with the `readonly` modifier instead.
Examples of code with the `fields` style:
<!--tabs-->
#### ❌ Incorrect
```ts
/* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
class Mx {
public static get myField1() {
return 1;
}
private get ['myField2']() {
return 'hello world';
}
}
```
#### ✅ Correct
```ts
/* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
class Mx {
public readonly myField1 = 1;
// not a literal
public readonly myField2 = [1, 2, 3];
private readonly ['myField3'] = 'hello world';
public get myField4() {
return `hello from ${window.location.href}`;
}
}
```
### The `getters` style
This style checks for any `readonly` fields that are assigned literal values, and requires them to be defined as getters instead.
This style pairs well with the [`@typescript-eslint/prefer-readonly`](prefer-readonly.md) rule,
as it will identify fields that can be `readonly`, and thus should be made into getters.
Examples of code with the `getters` style:
<!--tabs-->
#### ❌ Incorrect
```ts
/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
class Mx {
readonly myField1 = 1;
readonly myField2 = `hello world`;
private readonly myField3 = 'hello world';
}
```
#### ✅ Correct
```ts
/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
class Mx {
// no readonly modifier
public myField1 = 'hello';
// not a literal
public readonly myField2 = [1, 2, 3];
public static get myField3() {
return 1;
}
private get ['myField4']() {
return 'hello world';
}
}
```
## When Not To Use It
When you have no strong preference, or do not wish to enforce a particular style
for how literal values are exposed by your classes.