Content
View differences
Updated by Aleix Suau over 5 years ago
Right now we need to extend the OpModalComponent class in order to get a modal. This leads to modal components that have nothing to do with the modal but passing some configuration to it (closeOnEscape, closeOnOutsideClick). This generates closeOnOutsideClick), generating tight coupling, code repetition, or lack of isolation or mixed concerns (UI behaviour (modal), functionality(ie: workpackage button macro)).
isolation.
Ideally, the modal shouldn't know anything about the component that it hosts and should provide a clear API to configure, open, close... it through a service. Either way, the components (the one who calls the modal or the one that is rendered on it) shouldn't know anything about the modal and just inject its service to access the functionality.
The way it is implemented right now makes it difficult to refactor it. Add a library component (e.g. material) could be a better solution.
How it works:
* A directive (OpModalComponent) contains
Extend the functionality
* The component to be rendered in the modal extends the directive
* A service (OpModalService) creates dynamically the component and injects it into the portal. It also keeps a reference to the instantiated component class that is used to pass data and functionality around. so it:
Tasks:
* [ ] [x] Accepts a configuration object so there is no need to extend it to customize actions.
* [x] [ ] Is able to return data when it is closed.
The way it is implemented right now makes it difficult to refactor it. Add a library component (e.g. material) could be a better solution.
How it works:
* A directive (OpModalComponent) contains
Extend
* The component to be rendered in the modal extends the directive
* A service (OpModalService) creates dynamically the component and injects it into the portal. It also keeps a reference to the instantiated component class that is used to pass data and functionality around.
Tasks:
* [ ]
* [x]