* changed example to use toUpperCase() instead of .at(0) because .at(0) does not cause any errors since it is available in string and array
* Update satisfies-keyword@HD1UGOidp7JGKdW6CEdQ_.md
---------
Co-authored-by: pardha <pardha@Vs-MacBook-Pro.local>
Co-authored-by: Kamran Ahmed <kamranahmed.se@gmail.com>
TypeScript developers are often faced with a dilemma: we want to ensure that some expression matches some type, but also want to keep the most specific type of that expression for inference purposes.
For example:
```typescript
// Each property can be a string or an RGB tuple.
const palette = {
red: [255, 0, 0],
green: '#00ff00',
bleu: [0, 0, 255],
// ^^^^ sacrebleu - we've made a typo!
};
// We want to be able to use array methods on 'red'...
Notice that we’ve written `bleu`, whereas we probably should have written `blue`. We could try to catch that `bleu` typo by using a type annotation on palette, but we’d lose the information about each property.
```typescript
type Colors = 'red' | 'green' | 'blue';
type RGB = [red: number, green: number, blue: number];
const palette: Record<Colors,string|RGB> = {
red: [255, 0, 0],
green: '#00ff00',
bleu: [0, 0, 255],
// ~~~~ The typo is now correctly detected
};
// But we now have an undesirable error here - 'palette.red' "could" be a string.
const redComponent = palette.red.at(0);
```
The `satisfies` operator lets us validate that the type of an expression matches some type, without changing the resulting type of that expression. As an example, we could use `satisfies` to validate that all the properties of palette are compatible with `string | number[]`:
```typescript
type Colors = 'red' | 'green' | 'blue';
type RGB = [red: number, green: number, blue: number];