API reference

This reference contains a few different types of APIs:

  • Entry points which the plugin developer implements. These are called by the Studio host application (React Studio, Native Studio) whenever the host wants the plugin to do something or to provide some information.
  • Utility classes which are available in the Studio host environment. These classes include all the standard JavaScript API classes (such as Math and JSON) as well as a number of Neonto-specific utilities (such as Plugin and HttpClient).
  • Exporter object which the host application provides as an argument to some entry point methods. This is a class you can't instantiate yourself — an instance relevant to the export context is provided by the host as needed.
  • Object context methods which the host application provides on a plugin instance's object context. These give you access to some specific parts of the plugin instance such as the live inspector UI elements.
  • Inspector UI elements that a plugin can create for display in the Studio application UI.

Lifecycle of a plugin

It's useful to understand how a plugin gets loaded and applied within the host application.

A plugin is loaded from disk once when the Studio host application starts, and can be loaded again if the user triggers a reload in the Plugin Manager. At load time, the plugin's main JavaScript file (Main.js) is parsed and kept in memory.

Think of the plugin as similar to a class in most object-oriented programming languages. Its methods don't do anything on their own — they always need to be applied to a plugin instance. There can be any number of instances created from a single plugin. Each plugin instance is typically associated with something that the Studio user can manipulate, e.g. a particular element in a screen or a particular web service instance with its own configuration.

For each plugin instance, the plugin's JavaScript is executed within an instance-specific JavaScript object context. From the point of view of the plugin author, this object context is exposed as the this variable in the plugin script.

The object context has a number of purposes. Some properties on the object context are reserved by the Studio host application, i.e. the host expects to find certain type of content under that property name. These properties are called "entry points" because the host application calls the plugin to discover its features and perform actions using these properties.

It is also common to use the object context to store a plugin's internal data in memory. Many plugins use a property like this._data to keep an instance's internal state. However note that this data is not automatically saved. The plugin instance may get destroyed and reconstructed at the host application's convenience, at which time the object context is restored to the values that were loaded from your plugin's Main.js file.

Therefore if you want to store some data permanently (as part of the Studio document file), use the persist/unpersist entry points described later.

Types of entry points

Most entry points are methods; however they can also be regular properties that return an object value. This is typically the case if the property is something that shouldn't vary from one plugin instance to another. The Studio host application can load the property's value once and cache it for all instances.

A practical example of this kind of entry point is inspectorUIDefinition, which a plugin uses to tell Studio about the user interface it wants to display in Studio's "inspector" (the right-hand sidebar). For performance reasons, it's best that this UI definition is a declarative object rather than a method that gets executed each time.