Best Practices for Rendering Plugin Creation

Since the code of your rendering plugins is executed in a browser, it is important to write optimized code and pay special attention to performance issues. If your plugin works well on powerful machines, it might work unstable on other, less powerful, users' machines.

To ensure that your rendering plugin has been properly optimized to perform well in any of the above cases, check that:

• The rendering plugin prepares the data in a reasonable time.
• A sufficient number of tiles can be opened concurrently.

Also, follow the practices below while developing your rendering plugin. These practices allow you to avoid some of the most common performance issues related to data visualization.

For more information on general recommendations for developers on how to use Data Inspector Library components, see Best Practices for Developers.

Too Many Features Exist in Generated GeoJSON

Try not to represent all your data graphically, especially for large datasets. Otherwise, your rendering plugin can generate the GeoJSON that is too big to be rendered. Be aware that all sorts of users may use different browsers on different machines. So, do all your tests on the latest versions of Safari, Chrome, and Firefox and try them out on lower-end machines. It is recommended that you control the number of GeoJSON features to be rendered and not exceed the limit of memory allocated by browsers.

Having a big number of rendered objects on the map also makes it difficult to analyze the data visually since a lot of objects might be overlapped in the same area. That is why it is a good idea to create a variable in the code where users can specify a feature identifier, such as Vehicle ID, to render objects related only to this feature. Such filtering approach helps improve both analysis capability and performance.

Too Much Data Added to GeoJSON Properties

Do not try to add too many data details into GeoJSON tooltip and description informational properties. The concept of tooltip implies that only a short string is displayed in it, and for displaying detailed information description property is used. Still it is better not to add too much data into description as well.

Use the output of the Decoded Panel for a deeper analysis of GeoJSON features, geometries, and properties. Given that the entire GeoJSON generated by a rendering plugin with all the data in the feature properties passes through the Web Worker, much of your browser's allocated resources are consumed. That is why, too many additional information in the feature might cause your browser to crash.

Also, it is recommended to avoid usage of HTML in descriptions, it is better to use a key-value object, which will be represented as a table by InfoPanel.

If GeoJSON feature has a lot of underlying information, use the protobufRef property to map GeoJSON features generated by the plugin to the corresponding source data objects.

Too Many Expensive Operations While Processing Data

Always optimize your data processing operations since it could be megabytes (or even gigabytes) of decoded data that has to be processed locally by a rendering plugin. Do not overuse loops, recursions, data conversion, and data formatting (stringify, replace operations are too expensive).

Profile your rendering plugin before publishing to find and optimize any weak spots.

Test your plugins on a machine with mediocre performance to be sure that it does not cause browser crash. Note that currently the max number of tiles that can be rendered at the same time is 64.

Caution for Async GeoJSON Plugins

If you intend to implement the async getGeoJSONAsync function in your rendering plugins, you must make sure that promises always reject in case of runtime errors. Otherwise, if a promise is neither resolved nor rejected, plugin execution stalls, and users won't get any notifications about runtime errors in the plugin.

To make it easier, the recommended way is to use the ES6 async/await syntax. This ensures that any exceptions thrown inside any of the async functions called from the main getGeoJSONAsync function will always reject its promise. If you prefer using the Promise syntax over the async/await syntax sugar, you must be sure that these promises always reject in case of errors. Use try/catch to track any possible errors.