UNPKG

3.32 kBMarkdownView Raw
1# `class-literal-property-style`
2
3Ensures that literals on classes are exposed in a consistent style.
4
5When 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.
6When 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.
7
8## Rule Details
9
10This rule aims to ensure that literals exposed by classes are done so consistently, in one of the two style described above.
11By default this rule prefers the `fields` style as it means JS doesn't have to setup & teardown a function closure.
12
13:::note
14
15This 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.
16This is because these types can be mutated and carry with them more complex implications about their usage.
17
18:::
19
20### The `fields` style
21
22This style checks for any getter methods that return literal values, and requires them to be defined using fields with the `readonly` modifier instead.
23
24Examples of code with the `fields` style:
25
26<!--tabs-->
27
28#### ❌ Incorrect
29
30```ts
31/* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
32
33class Mx {
34 public static get myField1() {
35 return 1;
36 }
37
38 private get ['myField2']() {
39 return 'hello world';
40 }
41}
42```
43
44#### ✅ Correct
45
46```ts
47/* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
48
49class Mx {
50 public readonly myField1 = 1;
51
52 // not a literal
53 public readonly myField2 = [1, 2, 3];
54
55 private readonly ['myField3'] = 'hello world';
56
57 public get myField4() {
58 return `hello from ${window.location.href}`;
59 }
60}
61```
62
63### The `getters` style
64
65This style checks for any `readonly` fields that are assigned literal values, and requires them to be defined as getters instead.
66This style pairs well with the [`@typescript-eslint/prefer-readonly`](prefer-readonly.md) rule,
67as it will identify fields that can be `readonly`, and thus should be made into getters.
68
69Examples of code with the `getters` style:
70
71<!--tabs-->
72
73#### ❌ Incorrect
74
75```ts
76/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
77
78class Mx {
79 readonly myField1 = 1;
80 readonly myField2 = `hello world`;
81 private readonly myField3 = 'hello world';
82}
83```
84
85#### ✅ Correct
86
87```ts
88/* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
89
90class Mx {
91 // no readonly modifier
92 public myField1 = 'hello';
93
94 // not a literal
95 public readonly myField2 = [1, 2, 3];
96
97 public static get myField3() {
98 return 1;
99 }
100
101 private get ['myField4']() {
102 return 'hello world';
103 }
104}
105```
106
107## When Not To Use It
108
109When you have no strong preference, or do not wish to enforce a particular style
110for how literal values are exposed by your classes.
111
112## Attributes
113
114- Configs:
115 - [ ] ✅ Recommended
116 - [x] 🔒 Strict
117- [x] 🔧 Fixable
118- [ ] 💭 Requires type information