Content
View differences
Updated by Aleix Suau over 5 years ago
The state management of this component is very difficult to understand:
* Lack of a unidirectional data flow:
* Almost every component is subscribing to the board$ observable.
* This leads to the need of checking if the resource is cached (CachableAPIV3Resource.stale(id) || force)
* Inheritance/Typings are confusing: this.apiV3Service.boards.id(id).requireAndStream() calls CachableAPIV3Resource.requireAndStream which calls this.load. this.load points to the class CachableAPIV3Resource but the one that is called is APIv3BoardPath.
* Multiple components related but not integrated
* BoardPartitionedPageComponent
* BoardsMenuComponent
* BoardFilterComponent
* BoardListContainerComponent
* BoardListComponent
* BoardActionsRegistryService
* Functionality spread: Sometimes we call it through the BoardService and others directly through the APIV3 (this.apiV3Service.boards.id(id))
* Patterns mixing:
* Inheritance
* Dependency injection for components (parents)
* ViewChildren to access child
* Input / Outputs
* Improvement suggestions:
* Extract the use cases and scenarios
* Try to concentrate the state management on
* The parent component
* The BoardsService
* Try to integrate the flow of all the components/services
### NOTES
Refactor example BOARDS:
* Checkout code maintenance task created
* Bugs:
* [https://community.openproject.com/projects/openproject/work\_packages/34840/activity](https://community.openproject.com/projects/openproject/work_packages/34840/activity)
* [https://community.openproject.com/projects/openproject/work\_packages/35238](https://community.openproject.com/projects/openproject/work_packages/35238)
* [https://community.openproject.com/projects/openproject/work\_packages/35004/activity?query\_id=2432](https://community.openproject.com/projects/openproject/work_packages/35004/activity?query_id=2432)
* [https://community.openproject.com/projects/openproject/work\_packages/35563/activity?query\_id=2563](https://community.openproject.com/projects/openproject/work_packages/35563/activity?query_id=2563)
* Suggestion: [https://github.com/opf/openproject/pull/8778](https://github.com/opf/openproject/pull/8778)
* Last week 2 bugs related to boards:
* 403 Errors when fetching
* 429 too many requests
* Duplicated calls
* Good example of the architecture/patterns topic
* How it works:
* BoardListContainerComponent just fetches all the grid config and creates a BoardListComponent for every grid.widgets passing down the widget config.
* The BoardListComponent is responsible for calling the API endpoint the widget config indicates to get its data.
* 403:
* Problem: we are passing down data that can’t be rendered
* Solution: Smart parent component + Filtering allowed data in server, parent component
* 429:
* Problem: spread state management > lack of control > duplicated calls
* Solution: Smart parent component concentrates SM (BoardListContainerComponent) + presentational component (BoardListComponent) that is only updated by @input changes.
* Conclusion:
* It’s interesting to see bug as symptoms and try to fix the root cause of the problem. If not, we’ll apply solutions that extend the problem.
* Try to concentrate the state management in fewer components and make the others just presentational (dumb).
* Lack of a unidirectional data flow:
* Almost every component is subscribing to the board$ observable.
* This leads to the need of checking if the resource is cached (CachableAPIV3Resource.stale(id) || force)
* Inheritance/Typings are confusing: this.apiV3Service.boards.id(id).requireAndStream() calls CachableAPIV3Resource.requireAndStream which calls this.load. this.load points to the class CachableAPIV3Resource but the one that is called is APIv3BoardPath.
* Multiple components related but not integrated
* BoardPartitionedPageComponent
* BoardsMenuComponent
* BoardFilterComponent
* BoardListContainerComponent
* BoardListComponent
* BoardActionsRegistryService
* Functionality spread: Sometimes we call it through the BoardService and others directly through the APIV3 (this.apiV3Service.boards.id(id))
* Patterns mixing:
* Inheritance
* Dependency injection for components (parents)
* ViewChildren to access child
* Input / Outputs
* Improvement suggestions:
* Extract the use cases and scenarios
* Try to concentrate the state management on
* The parent component
* The BoardsService
* Try to integrate the flow of all the components/services
### NOTES
Refactor example BOARDS:
* Checkout code maintenance task created
* Bugs:
* [https://community.openproject.com/projects/openproject/work\_packages/34840/activity](https://community.openproject.com/projects/openproject/work_packages/34840/activity)
* [https://community.openproject.com/projects/openproject/work\_packages/35238](https://community.openproject.com/projects/openproject/work_packages/35238)
* [https://community.openproject.com/projects/openproject/work\_packages/35004/activity?query\_id=2432](https://community.openproject.com/projects/openproject/work_packages/35004/activity?query_id=2432)
* [https://community.openproject.com/projects/openproject/work\_packages/35563/activity?query\_id=2563](https://community.openproject.com/projects/openproject/work_packages/35563/activity?query_id=2563)
* Suggestion: [https://github.com/opf/openproject/pull/8778](https://github.com/opf/openproject/pull/8778)
* Last week 2 bugs related to boards:
* 403 Errors when fetching
* 429 too many requests
* Duplicated calls
* Good example of the architecture/patterns topic
* How it works:
* BoardListContainerComponent just fetches all the grid config and creates a BoardListComponent for every grid.widgets passing down the widget config.
* The BoardListComponent is responsible for calling the API endpoint the widget config indicates to get its data.
* 403:
* Problem: we are passing down data that can’t be rendered
* Solution: Smart parent component + Filtering allowed data in server, parent component
* 429:
* Problem: spread state management > lack of control > duplicated calls
* Solution: Smart parent component concentrates SM (BoardListContainerComponent) + presentational component (BoardListComponent) that is only updated by @input changes.
* Conclusion:
* It’s interesting to see bug as symptoms and try to fix the root cause of the problem. If not, we’ll apply solutions that extend the problem.
* Try to concentrate the state management in fewer components and make the others just presentational (dumb).