-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add data structures for chart plugin system #6028
Conversation
if (plugin instanceof Plugin) { | ||
plugin.install(); | ||
} else { | ||
plugin(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain a bit when plugin will be just a function ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This I could get some feedback. The issue was when someone needs to call plugin.install(...)
with arguments. I couldn't figure out a nice API design to let people pass arguments, so I chose this one.
for example, core chart presets could contains
plugins: [
() => new BarChartPlugin().install('bar'),
() => new PieChartPlugin().install('pie'),
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you address this by having the Plugin
take the config arguments via the constructor instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha. good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Umm, actually can't, because each vis will declare the ChartPlugin instance and export, so the preset only have access to the instance.
barPlugin.js
const plugin = new ChartPlugin(...);
export default plugin;
preset.js
import barPlugin from './barPlugin';
...
plugins: [barPlugin]
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Umm, on second thought, I can add .configure
to the Plugin
class
plugins: [
plugin1,
plugin2.configure({ key: 'abc' }),
]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, could the pattern instead be to export a class that has extended ChartPlugin
?
// BarPlugin.js
class BarPlugin extends ChartPlugin {
...
}
export default BarPlugin;
// preset.js
import BarPlugin from './BarPlugin';
...
const plugins = [
new BarPlugin({ config: 123 }),
];
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That could work too. At first I was like hmm is creating new class an overkill. Perhaps not. Just a bit more typing. and that allows override .register()
function + more customization.
class BarPlugin extends ChartPlugin {
constructor(config) {
super({ config, metadata, Chart, transformProps });
}
}
vs
const barPlugin = new ChartPlugin({ metadata, Chart, transformProps });
barPlugin.configure(config);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! and thanks for adding all the test!!
@@ -0,0 +1,16 @@ | |||
import Registry from './Registry'; | |||
|
|||
export default class LoaderRegistry extends Registry { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it simplify things to get rid of this class and just have the parent Registry
class have first class support for loaders out of the box?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
especially if the Registry
class already supports promises
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think simple registry could be useful for sync items like metadata. We can use this for other key-value stores we may have in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I meant have Registry
support sync and async all in one class. Like take either a loader
or a value
, and have the same promise-based API for getting either of them so you don't have to juggle different classes and different methods like get
and getAsPromise
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One distinction of the LoaderRegistry
from Registry
is it overrides .register()
to wrap returned value in a function.
Full disclosure. I started out with Registry
alone and at some point I encounter value that is a function (e.g. a class) and it gets quite confusing whether the value
can be returned immediately or it is a loader that needs to be executed. If both values and loaders can be stored in the same registry, I need another mechanism to indicate which is which. Separating into two classes help simplify that it is either just values or just loaders.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am revisiting the idea of having both in same Registry
again. May have to add explicit flag to keep track if it is a loader or not. You might have convinced me that one class that can do both will be better.
// use loadTransformProps for dynamic import (lazy-loading) | ||
loadTransformProps, | ||
|
||
// use Chart for immediate value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you explain a little more when you would want to use Chart
over loadChart
, or transformProps
over loadTransformProps
? especially since under the hood it seems that they are all transformed to loader func
s anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the chart is very small. Use Chart
, this will include Chart
in the bundle instead of spinning it of into a lazy-loaded bundle.
import MyChart from './MyChart';
...
Chart: MyChart,
...
if the chart is gigantic. Use loadChart
.
loadChart: () => import('./MyChart.jsx')
superset/assets/src/visualizations/core/registries/ChartComponentLoaderRegistry.js
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## master #6028 +/- ##
==========================================
+ Coverage 77.74% 77.81% +0.06%
==========================================
Files 46 46
Lines 9412 9446 +34
==========================================
+ Hits 7317 7350 +33
- Misses 2095 2096 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is doooooooope, really like how it turned out! I had one comment about the behavior when registering duplicate values but otherwise LGTM 🙌
} | ||
|
||
resetConfig() { | ||
// The child class can set default config |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
return this; | ||
} | ||
|
||
configure(config, replace = false) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dig the replace
👍
|
||
registerValue(key, value) { | ||
this.items[key] = { value }; | ||
delete this.promises[key]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my only comment at this point is whether we should throw an error if a value already exists, that would require people to consciously call .remove()
and possibly raise this to their attn if they weren't aware of it?
or we could just log a warning 🤔 wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may happen a lot though for the presets. For example, registering a preset that contains all common charts then override bar
chart with a new plugin. Some presets may reference another preset and override certain charts.
I think throwing an error would be too harsh.
Can add warning but then that will mean for every plugin we have to add .remove()
call before .register()
to avoid the warning. If every plugin does that, would a warning still be useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's a fair point, sgtm 👍
* add unit tests * add test structure * add unit tests for Registry * add LoaderRegistry unit test * add unit test for makeSingleton * add type check * add plugin data structures * simplify API * add preset tests * update test message * fix lint * update makeSingleton * update Plugin, Preset and unit test * revise Registry code * update unit test, add remove function * update test * update unit test * update plugin unit test * add .keys(), .entries() and .entriesAsPromise() * update test description
* add unit tests * add test structure * add unit tests for Registry * add LoaderRegistry unit test * add unit test for makeSingleton * add type check * add plugin data structures * simplify API * add preset tests * update test message * fix lint * update makeSingleton * update Plugin, Preset and unit test * revise Registry code * update unit test, add remove function * update test * update unit test * update plugin unit test * add .keys(), .entries() and .entriesAsPromise() * update test description
Classes
ChartMetadata
captures the definition of each visualization:name
,description
, thumbnail image.Plugin
a generic plugin class. All plugins should derive from this class. A plugin can be.configure()
to set/override configuration.ChartPlugin
this is how each type of visualization is defined.Preset
holds one or more presets and or plugins.Registry
is a key-value stores that facilitate plugin installation.value
orloader
..registerValue(key, value)
and.registerLoader(key, loader)
, respectively.registry.get(key)
will returns thevalue
or execute theloader
function and returns the result.registry.getAsPromise(key)
wraps the.get()
result into a Promise, which is useful for handling lazy-loading imports and treat both sync and async items the same way.ChartMetadataRegistry
,ChartComponentRegistry
andChartTransformPropsRegistry
are extended from the registry base classes above to hold metadata, the visualization component andtransformProps
(function that transformformData
into compatible parameters for each chart), respectively.Utility functions
makeSingleton
: create a function to get a singleton of the given class (aka.getInstance
)isRequired
: A function that throw error. Can be used for requiring certain function parameter by settingisRequired('fieldName')
as default value.After this PR is in, each visualization can be defined as a plugin using the data structures above.
Unit tests
@williaster @conglei @graceguo-supercat @michellethomas @mistercrunch @xtinec