You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, updating/refactoring the elastic-charts code base includes the risk of easily introducing circular dependencies. Resolving these can be time consuming and it makes PRs larger than necessary because of the required additional refactorings.
This issue tries to summarize approaches that can be used to reduce the risk of running into circular dependencies.
What is causing the risk?
The code base is organized in more general "base" code under packages/charts/src/state and specific code for different chart types in packages/charts/src/chart_types. Just as an analogy (I'm not suggesting refactoring anything towards being more OOP), in classic OOP we could consider the state code the classes and chart_types the implementations or instanced classes. The important bit is that the relationship is unidirectional state -> chart_types. The current code base handles this at just a very informal level and there are no restrictions in place to avoid two-way-dependencies. One of the main culprits is that what's called internal state at the moment is reimporting everything from chart_types to set up the chart specific renderers and selectors.
Analysis with dependency-cruiser
Once you start refactoring and run into a circular dependency it's hard to find the actual root cause. dependency-cruiser is a library to help with this and can point you to the exact files causing the problems, for example:
On top of this out-of-the-box-feature, one can describe custom rules for the validation. For example, we might want to warn or error out when someone tries to import from chart_types into state:
export*from"./foo";export*from"./bar";export*from"./baz";// stuff like this is esp. tricky:export*from"../some-other-dir-further-up";
linting type imports
This could improve readability and avoid some issues with imports. In Kibana some plugins enforce linting to have import type { .
refactor internal chart state
To avoid circular dependencies between state and chart_types, we can refactor InternalChartState:
break out the renderers to be only imported from chart/chart_container.tsx
break out the selectors into a dynamic registry. getInternalChartState would only define the registry, when setting up the store we can initialize the registry.
task summary
Potential tasks to improve code base related to circular dependencies:
At the moment, updating/refactoring the
elastic-charts
code base includes the risk of easily introducing circular dependencies. Resolving these can be time consuming and it makes PRs larger than necessary because of the required additional refactorings.This issue tries to summarize approaches that can be used to reduce the risk of running into circular dependencies.
What is causing the risk?
The code base is organized in more general "base" code under
packages/charts/src/state
and specific code for different chart types inpackages/charts/src/chart_types
. Just as an analogy (I'm not suggesting refactoring anything towards being more OOP), in classic OOP we could consider thestate
code the classes andchart_types
the implementations or instanced classes. The important bit is that the relationship is unidirectionalstate -> chart_types
. The current code base handles this at just a very informal level and there are no restrictions in place to avoid two-way-dependencies. One of the main culprits is that what's calledinternal state
at the moment is reimporting everything fromchart_types
to set up the chart specific renderers and selectors.Analysis with
dependency-cruiser
Once you start refactoring and run into a circular dependency it's hard to find the actual root cause. dependency-cruiser is a library to help with this and can point you to the exact files causing the problems, for example:
On top of this out-of-the-box-feature, one can describe custom rules for the validation. For example, we might want to warn or error out when someone tries to import from
chart_types
intostate
:Besides validation and analysis problems at hand,
dependency-cruiser
can generate charts that visualize the dependency graph:Note that this includes the custom rule we defined and highlights import from
chart_types
tostate
in red!Note that the rules could also be defined using
eslint
.linting imports/exports
Barrel files can be problematic in relation to circular dependencies too. (Background: https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/)
linting
type
importsThis could improve readability and avoid some issues with imports. In Kibana some plugins enforce linting to have
import type {
.refactor internal chart state
To avoid circular dependencies between
state
andchart_types
, we can refactorInternalChartState
:chart/chart_container.tsx
getInternalChartState
would only define the registry, when setting up the store we can initialize the registry.task summary
Potential tasks to improve code base related to circular dependencies:
dependency-cruiser
as part of the repo.chore(deps): dependency cruiser #2616
import type ...
chore(types): consistent type imports #2618
chore(refactor): refactor chart specific selectors out of state #2613
The text was updated successfully, but these errors were encountered: