likyh opened a new issue, #2744: URL: https://github.com/apache/incubator-devlake/issues/2744
## What and why to refactor Now, `config-ui` can run normally, but some small confusion when developing. We shall fix them. Detail as below: #### 1. we defined too many vars in global context (here means pages) and they related with each others by `useEffect` in parent and son components. Such as `activeTransformation` and `newTransformation` in **old code**: `activeTransformation` is defined in `create-blueprint.jsx`, and it passed like this: `create-blueprint.jsx` -> `DataTransformations.jsx` -> `DataTransformations.jsx` -> `ProviderTransformationSettings.jsx` -> `jira.jsx`. `setActiveTransformation` is defined in `create-blueprint.jsx`, but it is called in several `useEffect`. Another similar var `newTransformation` is defined in `DataTransformations.jsx`. That cause new developer need to spend a lot of unnecessary time to learn how the program works. #### solution We can do these actions to reduce learning curve for new developer: 1.a. only update local state (defined in current component by `useState`) in the function of `useEffect` which deps on the props (state passed by parent). 1.b. call the function `onXXX`/`handleXXX`/`setXXX` passed by parent only when listen on the local state binded with UI. 1.a and 1.b means we cannot use `useEffect` update parent state by depending on another parent state like: https://github.com/apache/incubator-devlake/blob/main/config-ui/src/pages/configure/settings/jira.jsx#L99-L105 1.c. use `useMemo` when a var is computed var and it has no side effect when updated. This action has been used in `activeTransformation` and we need to use it in all computed vars. It's a good way to help developer know how a state affect another state. 1.d. pack the logic of one data model in a hook and define some UI state in appropriate component instead of defining in global. https://github.com/apache/incubator-devlake/pull/2552/files#diff-6e1e4ac7737de3bc6a223b9020b4b7012f28750afc3c12a98517e1628f214ec4R80 The logic written in hook will be more readable than written in some different files or callbacks. and the data hook can avoid different update/query logic in different callback. 1.e. all of these ways can help us reduct the number of `useState` and `useEffect`. But special cases always exist. If we have to pass state and callback from pageComponent to detailComponent, let's use Typescript to make how to use them clear. An example: https://github.com/apache/incubator-devlake/blob/main/config-ui/src/pages/blueprints/create-blueprint.jsx#L591-L594 `addProjectTransformation` call `setConfiguredProject` in `create-blueprint.jsx`; `addProjectTransformation` passed to `DataTransformations.jsx`; and it passed to `StandardStackedList.jsx` as `onAdd` and `onChange`; https://github.com/apache/incubator-devlake/blob/main/config-ui/src/pages/blueprints/create-blueprint.jsx#L596-L599 `addBoardTransformation` and `setConfiguredBoard` has the similar path. But notice, they have similar name and similar using, but the param of`setConfiguredProject` is ID and the param of`setConfiguredBoard` is object ... Typescript can help us know how to use a state or callback when it has been passed many times in son components, and avoid new committers, who don't notice the gap, using these setter function wrong. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
