1 | # `class-literal-property-style`
|
2 |
|
3 | Ensures that literals on classes are exposed in a consistent style.
|
4 |
|
5 | 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.
|
6 | 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.
|
7 |
|
8 | ## Rule Details
|
9 |
|
10 | This rule aims to ensure that literals exposed by classes are done so consistently, in one of the two style described above.
|
11 | By default this rule prefers the `fields` style as it means JS doesn't have to setup & teardown a function closure.
|
12 |
|
13 | :::note
|
14 |
|
15 | 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.
|
16 | This 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 |
|
22 | This style checks for any getter methods that return literal values, and requires them to be defined using fields with the `readonly` modifier instead.
|
23 |
|
24 | Examples of code with the `fields` style:
|
25 |
|
26 |
|
27 |
|
28 | #### ❌ Incorrect
|
29 |
|
30 | ```ts
|
31 | /* eslint @typescript-eslint/class-literal-property-style: ["error", "fields"] */
|
32 |
|
33 | class 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 |
|
49 | class 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 |
|
65 | This style checks for any `readonly` fields that are assigned literal values, and requires them to be defined as getters instead.
|
66 | This style pairs well with the [`@typescript-eslint/prefer-readonly`](prefer-readonly.md) rule,
|
67 | as it will identify fields that can be `readonly`, and thus should be made into getters.
|
68 |
|
69 | Examples of code with the `getters` style:
|
70 |
|
71 |
|
72 |
|
73 | #### ❌ Incorrect
|
74 |
|
75 | ```ts
|
76 | /* eslint @typescript-eslint/class-literal-property-style: ["error", "getters"] */
|
77 |
|
78 | class 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 |
|
90 | class 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 |
|
109 | When you have no strong preference, or do not wish to enforce a particular style
|
110 | for 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
|