In this episode we will look at the approach of plugins for NGV, our Modern 3D Viewer framework. This is part of the NGV series.

Targeting developers

One approach is to target non-developer end users with a "just-click-to-enable" solution. The drawback is that you need to write and maintain a lot of extra code, documentation and that makes it both time consuming and rigid.
As a consequence, we target developers and focus on making it easy for them. There is actually a lot of technology around plugins and reusable code that we can leverage: git, ES modules, docker...
One other big simplification is to have no external plugins: to extend the software users should fork the project and build it.

Maintainability / reusability

Plugins are good for maintainable solutions. With plugins you are forced to think about what is core and what is not; what should be extensible or replaceable. You need to introduce abstractions, interfaces and that makes the code more isolated and easier to understand. In addition, you write documentation and instructions to help people outside of the core developers understand your APIs: that makes it really easier for everyone.

An example, we have created the pluginngv-plugin-cesium-widgetto isolate low-level Cesium code from applications code. We plan to have dozens of applications: having common code in a plugin allows us to share code but also concepts between applications. The plugin is generic and we expose interfaces for configuring it: the plugin can handle any configuration, it is future-proof.

@customElement('ngv-plugin-cesium-widget')
exportclassNgvPluginCesiumWidgetextendsLitElement{
publicviewer:CesiumWidget;

@property({type:Object})
cesiumContext:IngvCesiumContext;

@property({type:Object})
modelCallback:(name:string,model:Model)=>void;

Extension / Customization

With a plugin system the user has the power to go beyond configuration. The solution can be customized and even extended.

For example, all geospatial applications have a search bar, but none have the same: different backends, different formats, different features.

A search plugin can come with predefined providers (ex: OpenstreetMap Nominatim) and allow you to provide yours (ex: Pelias, Photon,...).

These providers are independent of that application and can easily be shared or contributed upstream.

In addition, the search plugin can be completely replaced by another implementation, as long as it obeys to the underlying interface.

for(constpcofdescr.config.providers){
constinitialize=providerInitializers[pc.name];
if(!initialize){
console.error("could not find provider",pc.name,"skipping it");
continue;
}
constprovider=initialize(pc.config);
this.providers.push(provider);
}

this.autocomplete=newAutocomplete(this.autocompleteRef.value,{

search:this.search.bind(this),
onSubmit:this.onSubmit.bind(this),
renderResult:this.renderResult.bind(this),
getResultValue:this.getResultValue.bind(this),
});

Standards

Very close to the idea of "plugins" is the concept of "modules". Indeed, Ecmascript modules are the technical way we "pack" and make available our plugins, internally, in the NGV framework.

In a similar way, web components, are the technical standard that allows us to expose UI plugins to the DOM.

We can also see git as the fundamental tool that allows our plugin strategy, by empowering users to fork, adapt, contribute.

Conclusion

Our solution to the plugin problem is an architecture relying on standard, leveraging developer know-how and ecosystem, it allows for easier to understand, isolated and more maintainable code.

Have you designed a plugin system? Or have you started thinking about it? Let me know your feedback in comments.