You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -74,6 +71,59 @@ It's important that when you write CSS/SASS selectors using classes, IDs, and at
74
71
capitalization in the CSS matches that used in the HTML. HTML and CSS follow different case sensitivity rules, and we can avoid subtle gotchas by ensuring we use the
75
72
same capitalization in both of them.
76
73
74
+
### How to generate ids?
75
+
76
+
When labeling elements (and for some other accessibility tasks) you will often need
77
+
ids. Ids must be unique within the page i.e. no duplicate ids in the rendered DOM
78
+
at any time.
79
+
80
+
Since we have some components that are used multiple times on the page, you must
81
+
make sure every instance of that component has a unique `id`. To make the generation
82
+
of those `id`s easier, you can use the `htmlIdGenerator` service in the `@elastic/eui`.
83
+
84
+
A React component could use it as follows:
85
+
86
+
```jsx
87
+
import { htmlIdGenerator } from'@elastic/eui';
88
+
89
+
render() {
90
+
// Create a new generator that will create ids deterministic
Each id generator you create by calling `htmlIdGenerator()` will generate unique but
100
+
deterministic ids. As you can see in the above example, that single generator
101
+
created the same id in the label's `htmlFor` as well as the input's `id`.
102
+
103
+
A single generator instance will create the same id when passed the same argument
104
+
to the function multiple times. But two different generators will produce two different
105
+
ids for the same argument to the function, as you can see in the following example:
106
+
107
+
```js
108
+
constgeneratorOne=htmlIdGenerator();
109
+
constgeneratorTwo=htmlIdGenerator();
110
+
111
+
// Those statements are always true:
112
+
// Same generator
113
+
generatorOne('foo') ===generatorOne('foo');
114
+
generatorOne('foo') !==generatorOne('bar');
115
+
116
+
// Different generator
117
+
generatorOne('foo') !==generatorTwo('foo');
118
+
```
119
+
120
+
This allows multiple instances of a single React component to now have different ids.
121
+
If you include the above React component multiple times in the same page,
122
+
each component instance will have a unique id, because each render method will use a different
123
+
id generator.
124
+
125
+
You can also use this service outside of React.
126
+
77
127
## API endpoints
78
128
79
129
The following style guide rules are targeting development of server side API endpoints.
@@ -90,7 +140,8 @@ API routes must start with the `/api/` path segment, and should be followed by t
90
140
91
141
Kibana uses `snake_case` for the entire API, just like Elasticsearch. All urls, paths, query string parameters, values, and bodies should be `snake_case` formatted.
92
142
93
-
*Right:*
143
+
_Right:_
144
+
94
145
```
95
146
POST/api/kibana/index_patterns
96
147
{
@@ -108,19 +159,19 @@ The following style guide rules apply for working with TypeScript/JavaScript fil
108
159
109
160
### TypeScript vs. JavaScript
110
161
111
-
Whenever possible, write code in TypeScript instead of JavaScript, especially if it's new code.
162
+
Whenever possible, write code in TypeScript instead of JavaScript, especially if it's new code.
112
163
Check out [TYPESCRIPT.md](TYPESCRIPT.md) for help with this process.
113
164
114
165
### Prefer modern JavaScript/TypeScript syntax
115
166
116
167
You should prefer modern language features in a lot of cases, e.g.:
117
168
118
-
* Prefer `class` over `prototype` inheritance
119
-
* Prefer arrow function over function expressions
120
-
* Prefer arrow function over storing `this` (no `constself=this;`)
121
-
* Prefer template strings over string concatenation
122
-
* Prefer the spread operator for copying arrays (`[...arr]`) over `arr.slice()`
123
-
* Use optional chaining (`?.`) and nullish Coalescing (`??`) over `lodash.get` (and similar utilities)
169
+
- Prefer `class` over `prototype` inheritance
170
+
- Prefer arrow function over function expressions
171
+
- Prefer arrow function over storing `this` (no `constself=this;`)
172
+
- Prefer template strings over string concatenation
173
+
- Prefer the spread operator for copying arrays (`[...arr]`) over `arr.slice()`
174
+
- Use optional chaining (`?.`) and nullish Coalescing (`??`) over `lodash.get` (and similar utilities)
124
175
125
176
### Avoid mutability and state
126
177
@@ -131,7 +182,7 @@ Instead, create new variables, and shallow copies of objects and arrays:
131
182
```js
132
183
// good
133
184
functionaddBar(foos, foo) {
134
-
constnewFoo= {...foo, name:'bar'};
185
+
constnewFoo= {...foo, name:'bar'};
135
186
return [...foos, newFoo];
136
187
}
137
188
@@ -250,8 +301,8 @@ const second = arr[1];
250
301
251
302
### Magic numbers/strings
252
303
253
-
These are numbers (or other values) simply used in line in your code. *Do not
254
-
use these*, give them a variable name so they can be understood and changed
304
+
These are numbers (or other values) simply used in line in your code. _Do not
305
+
use these_, give them a variable name so they can be understood and changed
255
306
easily.
256
307
257
308
```js
@@ -325,19 +376,18 @@ import inSibling from '../foo/child';
325
376
Don't do this. Everything should be wrapped in a module that can be depended on
326
377
by other modules. Even things as simple as a single value should be a module.
327
378
328
-
329
379
### Only use ternary operators for small, simple code
330
380
331
-
And *never* use multiple ternaries together, because they make it more
381
+
And _never_ use multiple ternaries together, because they make it more
332
382
difficult to reason about how different values flow through the conditions
333
383
involved. Instead, structure the logic for maximum readability.
334
384
335
385
```js
336
386
// good, a situation where only 1 ternary is needed
337
-
constfoo=(a === b)?1:2;
387
+
constfoo= a === b ?1:2;
338
388
339
389
// bad
340
-
constfoo=(a === b)?1:(a === c)?2:3;
390
+
constfoo= a === b ?1: a === c ?2:3;
341
391
```
342
392
343
393
### Use descriptive conditions
@@ -475,13 +525,12 @@ setTimeout(() => {
475
525
476
526
Use slashes for both single line and multi line comments. Try to write
477
527
comments that explain higher level mechanisms or clarify difficult
478
-
segments of your code. *Don't use comments to restate trivial things*.
528
+
segments of your code. _Don't use comments to restate trivial things_.
479
529
480
-
*Exception:* Comment blocks describing a function and its arguments
530
+
_Exception:_ Comment blocks describing a function and its arguments
481
531
(docblock) should start with `/**`, contain a single `*` at the beginning of
482
532
each line, and end with `*/`.
483
533
484
-
485
534
```js
486
535
// good
487
536
@@ -546,11 +595,17 @@ You can read more about these two ngReact methods [here](https://github.com/ngRe
546
595
Using `react-component` means adding a bunch of components into angular, while `reactDirective` keeps them isolated, and is also a more succinct syntax.
0 commit comments