2019-10-30 10:22:59 +01:00
|
|
|
# 🦉 Environment 🦉
|
|
|
|
|
|
2019-11-11 17:31:34 +01:00
|
|
|
## Content
|
|
|
|
|
|
|
|
|
|
- [Overview](#overview)
|
|
|
|
|
- [Setting an Environment](#setting-an-environment)
|
2019-11-26 13:20:54 +01:00
|
|
|
- [Using a sub environment](#using-a-sub-environment)
|
2019-11-11 17:31:34 +01:00
|
|
|
- [Content of an Environment](#content-of-an-environment)
|
|
|
|
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
2022-01-13 10:26:14 +01:00
|
|
|
An environment is a shared object given to all components in a tree. It is not
|
|
|
|
|
used by Owl itself, but it is useful for application developers to provide a
|
|
|
|
|
simple communication channel between components (in addition to the props).
|
|
|
|
|
|
|
|
|
|
The `env` given to the [`App`](app.md) is assigned to the `env` component
|
|
|
|
|
property.
|
2019-10-30 10:22:59 +01:00
|
|
|
|
|
|
|
|
```
|
|
|
|
|
Root
|
|
|
|
|
/ \
|
|
|
|
|
A B
|
|
|
|
|
```
|
|
|
|
|
|
2022-01-13 10:26:14 +01:00
|
|
|
Also, the `env` object is frozen when the application is started. This is done
|
|
|
|
|
to ensure a simpler mental model of what's happening in runtime. Note that it
|
|
|
|
|
is only shallowly frozen, so sub objects can be modified.
|
2019-10-30 10:22:59 +01:00
|
|
|
|
2019-10-31 22:45:22 +01:00
|
|
|
## Setting an environment
|
|
|
|
|
|
2022-01-13 10:26:14 +01:00
|
|
|
The correct way to customize an environment is to simply give it to the `App`,
|
|
|
|
|
whenever it is created.
|
2019-10-31 22:45:22 +01:00
|
|
|
|
|
|
|
|
```js
|
2020-10-27 14:41:09 +01:00
|
|
|
const env = {
|
2019-10-31 22:45:22 +01:00
|
|
|
_t: myTranslateFunction,
|
|
|
|
|
user: {...},
|
|
|
|
|
services: {
|
|
|
|
|
...
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
2022-01-13 10:26:14 +01:00
|
|
|
new App(Root, { env }).mount(document.body);
|
2019-10-31 22:45:22 +01:00
|
|
|
|
2022-01-13 10:26:14 +01:00
|
|
|
// or alternatively
|
|
|
|
|
mount(App, document.body, { env });
|
2019-10-31 22:45:22 +01:00
|
|
|
```
|
2019-11-11 17:31:34 +01:00
|
|
|
|
2019-11-26 13:20:54 +01:00
|
|
|
## Using a sub environment
|
|
|
|
|
|
|
|
|
|
It is sometimes useful to add one (or more) specific keys to the environment,
|
|
|
|
|
from the perspective of a specific component and its children. In that case, the
|
|
|
|
|
solution presented above will not work, since it sets the global environment.
|
|
|
|
|
|
2022-01-24 14:39:12 +01:00
|
|
|
There are two hooks for this situation: [`useSubEnv` and `useChildSubEnv`](hooks.md#usesubenv-and-usechildsubenv).
|
2019-11-26 13:20:54 +01:00
|
|
|
|
|
|
|
|
```js
|
2022-01-13 10:26:14 +01:00
|
|
|
class SomeComponent extends Component {
|
|
|
|
|
setup() {
|
|
|
|
|
useSubEnv({ myKey: someValue }); // myKey is now available for all child components
|
2019-11-26 13:20:54 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2019-11-11 17:31:34 +01:00
|
|
|
## Content of an Environment
|
|
|
|
|
|
2022-01-13 10:26:14 +01:00
|
|
|
The `env` object content is totally up to the application developer. However,
|
|
|
|
|
some good use cases for additional keys in the environment are:
|
2019-11-11 17:31:34 +01:00
|
|
|
|
|
|
|
|
- some configuration keys,
|
|
|
|
|
- session information,
|
2020-04-17 12:12:02 +02:00
|
|
|
- generic services (such as doing rpcs).
|
2022-01-13 10:26:14 +01:00
|
|
|
- other utility functions that one want to inject, such as a translation function.
|
2019-11-11 17:31:34 +01:00
|
|
|
|
|
|
|
|
Doing it this way means that components are easily testable: we can simply
|
|
|
|
|
create a test environment with mock services.
|