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
It seems I can use this feature to clean up the code a lot.
A lot of the charts have similar properties & methods (WithTitle, With..., etc) and so this can be refactored to an embedded type.
Some examples of embedded types I could make are:
AggregatableChart which provides the ShowAverages ShowSums etc
BaseAxisChart which has height name values etc
The text was updated successfully, but these errors were encountered:
Due to the fact that there are no generics, I will switch from the builder-based API to the more common functional options-based API as described here.
Using this approach, the library will still have a type-safe and concise API with sensible defaults and a thin abstraction to allow more idiomatic Go code.
edit: In this codebase, it seems the varadiac configuration pattern will be better due to naming problems.
LineChartConfig vs BarChartConfig is a lot better than
LineChartTitle, BarChartTitle, LineChart etc
Frappe/charts is best represented with OOP and Go doesn't seem too good at that. Every approach I can think of has redundant code and so I think just leaving this library as it is right now is fine since the lib is tiny anyways.
It seems I can use this feature to clean up the code a lot.
A lot of the charts have similar properties & methods (WithTitle, With..., etc) and so this can be refactored to an embedded type.
Some examples of embedded types I could make are:
AggregatableChart which provides the ShowAverages ShowSums etc
BaseAxisChart which has height name values etc
The text was updated successfully, but these errors were encountered: