| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Now the runtime state lives inside the model (instead of being
associated to the static settings via a map), which simplifies state
management. Static settings are now located inside the runtime models,
so we must create tests to make sure that the settings are being
persisted correctly. The contents of the config file are now generated
as a view of store (instead of a snapshot), which adds flexibility.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
| |
|
|
|
|
|
|
|
|
| |
In the main process, it is optional to specify the ID of a Profile or a
Service. The missing ID will be filled in with a randomly generated one.
Moreover, services without a profile will get a profile generated with
the same name.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
| |
|
|
| |
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
| |
|
|
| |
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
| |
|
|
|
|
|
|
| |
* stores: reactive data structures to hold application state
* controllers: subscribe to store changes and call store actions in
response to external events from services
* services: integrate with the nodejs and electron environment (should
be mocked for unit testing)
|
| |
|
|
|
|
|
|
| |
The architecture in the main process is split into 3 main parts:
* services: interfaces for services are injected into the stores through
the MainEnv interface (for testability)
* services/impl: electron-specific implementations of services
* stores: the actions of the stores can invoke (asynchronous) services
|
| |
|
Kristóf Marussy