The Script Kit Process Lifecycle

Script Kit Process Lifecycle: Understanding the Process/Script/Prompt Relationships

The Idle Process

When the app starts up, it initiates an idle process. This process does the following:

  1. Loads ~/.kit/run/app-prompt.js to preload the Script Kit libraries from the SDK

Note: This will also preload the platform-specific code

  1. Idles and waits for the user to submit a script
  2. Enables quick script launching since the process is always ready to go

Script Execution and Prompts

Prompts play a crucial role in Script, but they don't come into play unless the script uses one of the following prompts (grouped by similarity)

  • arg, mini, micro
  • fields and form
  • div and splash (the install screen, used internally)
  • editor and textarea(textarea is pretty much legacy, just use editor)
  • hotkey
  • chat
  • mic
  • drop

Since everything in Script Kit is done "just in time," the app doesn't know what will display until the script hits a prompt. When a prompt is encountered, the following occurs:

  1. Sends prompt type/data to the app
  2. The app displays the data to the user (e.g., list or HTML)
  3. Waits for a submit action before proceeding to the next step

Each time a prompt is hit, the script waits for the user to submit the prompt before moving forward. When the user triggers the submit event, the script will continue exectuing with the data received from the user. While a script is waiting for the "submit" event from the app, you can leverage a few event handlers such as:

  • onInit (right after the app receives the prompt config)
  • onInput
  • onBlur
  • onChoiceFocus
  • onSubmit (right before the script continues from the prompt. Last chance to get data from the app)
  • and more...

These are all based on the following interface:

export interface ChannelHandler {
  (input?: string, state?: AppState): void | Promise<void>
}

These "ChannelHandlers" are how the app communicates back to the script. These deserve a blog post of their own.

The Main Menu

The main menu is a script just like any you authored. The main shortcut (cmd+; by default) will the the ~/.kit/run/app-prompt.js to run the ~/.kit/main/index.js script.

Any custom keyboard shortcuts (or other script triggers) you've set up will load your ~/.kenv/scripts/your-script.js and will not load the main menu.

What makes the main menu feel different is that it's a script that loads another script. In JavaScript terms, it's a module which imports another module.

Also, the default behavior for many prompts onEscape handler is to "run the main menu script", so it can definitely feel more special than your script. Rest assured that the main menu is "just a script" that leverages many of more advanced Script Kit features.

Script Termination and Process Management

Now that the process has loaded the SDK and has imported your script, the process will terminate once the script has run all of its code. So the script has either run out of promises/prompts to wait for, event handlers to listen to, or you've blurred/escaped or triggered another event from the app that told the script to end prematurely.

While your script is running, the Script Kit app will always start another idle process in the background to be ready for the next script sent by the user.

Recap

The core basics of the Script Kit process lifecycle can be summarized as follows:

  1. The app starts an idle process that preloads the Script Kit SDK.
  2. The idle process waits for the the script (AKA JavaScript module)
  3. When a script is sent to the idle process, the app runs through the script and displays prompts when necessary.
  4. The process waits for the user to input and submit for each prompt.
  5. Once the script has executed all of its code, the process terminates.
Discuss Post