mirror of
https://github.com/elastic/kibana.git
synced 2025-06-28 11:05:39 -04:00
8453fe820a
## Summary
The spread operator is costly and put pressure on GC. It should be
avoided when possible, especially in loops.
This PR adapts a lot of `reduce` calls in the codebase to remove the
usages of the diabolic spread operator, when possible.
Note: the PR is not fully exhaustive. I focused on the server-side, as
we're more directly impacted than on browser-side code regarding
performances.
## Removing `...` usages in `kittens.reduce()`
For `reduce` loops, the spread operator can usually easily be replaced:
#### - setting a value on the accum object and returning it
#### BAD
```ts
return this.toArray().reduce(
(acc, renderer) => ({
...acc,
[renderer.name]: renderer,
}),
{} as Record<string, ExpressionRenderer>
);
```
#### GOOD
```ts
return this.toArray().reduce((acc, renderer) => {
acc[renderer.name] = renderer;
return acc;
}, {} as Record<string, ExpressionRenderer>);
```
#### - assigning values to the accum object and returning it
#### BAD
```ts
const allAggs: Record<string, any> = fieldAggRequests.reduce(
(aggs: Record<string, any>, fieldAggRequest: unknown | null) => {
return fieldAggRequest ? { ...aggs, ...(fieldAggRequest as Record<string, any>) } : aggs;
},
{}
);
```
#### GOOD
```ts
const allAggs = fieldAggRequests.reduce<Record<string, any>>(
(aggs: Record<string, any>, fieldAggRequest: unknown | null) => {
if (fieldAggRequest) {
Object.assign(aggs, fieldAggRequest);
}
return aggs;
},
{}
);
```
#### - pushing items to the accum list and returning it
#### BAD
```ts
const charsFound = charToArray.reduce(
(acc, char) => (value.includes(char) ? [...acc, char] : acc),
[] as string[]
);
```
#### GOOD
```ts
const charsFound = charToArray.reduce((acc, char) => {
if (value.includes(char)) {
acc.push(char);
}
return acc;
}, [] as string[]);
```
## Questions
#### Are you sure all the changes in this are strictly better for
runtime performances?
Yes, yes I am.
#### How much better?
Likely not much.
#### Are you planning on analyzing the perf gain?
Nope.
#### So why did you do it?
I got tired of seeing badly used spread operators in my team's owned
code, and I had some extra time during on-week, so I spent a few hours
adapting the usages in all our runtime/production codebase.
#### Was it fun?
Take your best guess.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| index.ts | ||
| jest.config.js | ||
| kibana.jsonc | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
@kbn/core-saved-objects-api-server-internal
This package contains the internal implementation of core's server-side savedObjects client and repository.
Structure of the package
@kbn/core-saved-objects-api-server-internal
- /src/lib
- repository.ts
- /apis
- create.ts
- delete.ts
- ....
- /helpers
- /utils
- /internals
lib/apis/utils
Base utility functions, receiving (mostly) parameters from a given API call's option (e.g the type or id of a document, but not the type registry).
lib/apis/helpers
'Stateful' helpers. These helpers were mostly here to receive the utility functions that were extracted from the SOR. They are instantiated with the SOR's context (e.g type registry, mappings and so on), to avoid the caller to such helpers to have to pass all the parameters again.
lib/apis/internals
I would call them 'utilities with business logic'. These are the 'big' chunks of logic called by the APIs. E.g preflightCheckForCreate, internalBulkResolve and so on.