Events

Right now there are four ULLD specific events that you can hook into as a developer.

• onBuild
• onRestore
• onSync
• onBackup

All of these methods are available in your pluginConfig.ulld.json file, and of course in the developerConfigSchema exported from @ulld/configschema/developer. They are optional strings that align with an export field in your plugin's package.json file. Like other fields that align with the export property, the function must be exported as that file's default export.

Because some of these methods accept any json serializable object, and will return that same type in another method, it is recommended that you type these methods using the uniform EventMethods type exported from @ulld/configschema/types. That typing approach might look like:

import { EventMethods as EMS, EventMethod as EM } from "@ulld/configschema/types"
import { PluginEventsConfig } from "@ulld/types"
 
type SyncData = {
    myData: string
    myOtherData: number // etc...
}
 
export type EventMethods = EMS<SyncData>
 
export type EventMethod<K extends keyof PluginEventsConfig> = EM<SyncData, K>

The above approach will ensure type safety across the different methods, as the SyncData type will be serialized using superjson¹ in the onBackup method, and then returned during the onRestore method.

The intended function of these events are as follows:

1. onBackup
   All generated data returned from this function will be serialized using superjson and returned to the user in a json file.
2. onRestore
   This is the other half of onBackup. This method will be given the same data that was returned by the onBackup method, and it is up to you the developer to store it in their database (make sure to check that you are not storing duplicates) and generate any necessary changes that the user's data might indicate.
3. onBuild
   This method is called once during the build process, after the core of the build is in place. This method receives 3 arguments, an object containing a set of paths as the PathMap type², their validated AppConfigSchemaOutput³, and their generated BuildStaticDataOutput⁴. These paths will be the absolute path to various directories and files in that user's new application. This is your opportunity to copy over any data you might need to their public folder, generate a static json file, or create a scss file based on their configuration. Keep in mind, static json files can be changed after the app is compiled, but those changes will not be reflected in the user's application until their app is rebuilt. It is only realistic to create file content directly in the user's file system if that content will not change over the period with which they user their application.
4. onSync
   This method is likely the most important of the currently available methods. This method will be given an array of MdxNote classes and expect you, the developer, to gather whatever information is needed and store it in that user's database.