TypeScript Apps (Beta)
TypeScript App mode is currently in Beta.
TypeScript mode gives improved development tooling and performance for apps.
Overview
Highlights for apps in TypeScript mode include:
Support for modern JavaScript and TypeScript syntax
Build-time type checking, reducing errors and improving auto-complete
async
/await
support, allowing control over concurrencyApp module support for sharing code across views
App package support for managing sub-projects within the app codebase
NPM dependency support for sharing code across apps, or including external libraries
Asynchronous functions
In standard JourneyApps apps, many functions appear synchronous, even though asynchronous execution occurs behind the scenes.
In TypeScript mode, these functions are all explicitly asynchronous, and return a Promise. It is recommended to use the await
keyword with these functions.
The database APIs function the same as in CloudCode. See the async & await documentation for details.
Other notable async functions include fetch
, journey.dialog
, actionSheet
, optionList
.
Tip
Async functions and Promises are highlighted using italics in OXIDE. Use this as a hint for when to use the await
keyword.
SharedJS / App modules
In standard JourneyApps apps, SharedJS (app.js
in OXIDE) is available to define global functions, usable from any view. In TypeScript mode, this is replaced with app modules. These are files that can be imported from views.
Functions defined in app modules must be explicitly exported and imported to be used from views. For details, see the TypeScript handbook.
By default, app modules are created in a lib
folder. These can be imported into your views by including import * as mymodule from "~/lib/mymodule"
at the top of your view TS. See an example below.
Example
Send a push notification from a view using a global function from an app module:
Tip
Add the App Modules panel (available from the command palette) to your views workspace to make it easier to manage your modules.
App packages
App packages are available as a way to manage custom sub-projects within your application's codebase. Please see the documentation for further information.
Node.js packages
Node.js package dependencies can be added and imported from views.
Some restrictions:
Types for the package are used during the build and deploy process, but not available during editing in OXIDE yet.
The package must be compatible with Webpack without using additional loaders or configuration.
The code runs in the context of a Web Worker. Many standard browser APIs are not available, and some Web Worker APIs are also disabled.
DOM APIs are not available. It is not possible to add any form of visual components via NPM dependencies yet.
XMLHttpRequest is not available. The package must use
fetch
instead.
Example - Add a Node.js package to your app and import it from a view
See this section about adding/managing external dependencies:
After adding the Node.js package to your app it can be imported in any of your app's views. In this example we are formatting a date using luxon:
Default TypeScript settings
The default TypeScript version for apps is >= 4.1.3
but is exactly specified within an app's yarn.lock
file. The default TSConfig settings for apps include the following:
Migrating an app to TypeScript
Commit any changes to the app.
Run the Migrate app to TypeScript action in OXIDE (via the command palette). Note that this action is only available in advanced IDE mode.
The action does the following automatically:
Add package.json and yarn.lock files to the project.
Rename view scripts from
.js
->.ts
.Move SharedJS to
lib/index.ts
.
No code changes are performed automatically. Once the above migration has completed, code will have to be fixed in each view. At this point, attempting to deploy may result in a large number of build errors.
Generally, OXIDE should pick up a large portion of code changes that must be performed. Some of these have quick-fixes available. Most notably, since many APIs are now async, the code must be updated to include await
in the relevant places.
Once OXIDE doesn't display any errors in view code anymore, deploy and test the application.
Last updated