Configuration
Setting up a view
The first step to building an Airplane view is to write its configuration. This contains the core
metadata of the view, like the view name and environment variables. It includes all information
aside from the actual code that is executed when the view is run.
View configuration was previously accomplished using a yaml-based view definition. This new, inline
view configuration allows tasks to be configured and developed in the same file.
To define a view, the JavaScript SDK provides a function
airplane.view(...)
,
which takes two parameters: the view configuration and the view component. The result of
airplane.view
must be the default export of the file.tsxCopied1// my_view.airplane.tsx2import { Title } from "@airplane/views";3import airplane from "airplane";4const MyView = () => {5return <Title>Hello World!</Title>;6};7export default airplane.view(8// View configuration9{10slug: "my_view",11name: "My View",12description: "This is my view!",13},14// View component15MyView16);
Airplane will only discover views that are the default export of files ending in
.airplane.tsx
, .airplane.jsx
, .view.tsx
, or .view.jsx
.Reference
slug
REQUIRED
- Be fewer than 50 characters long.
- Use only lowercase letters, numbers and underscores.
- Start with a lowercase later.
name
default: same value as slug
A user-facing name for the view. This can be changed.
description
A user-facing description for the view. Supports markdown.
envVars
Using TypeScript
All views components and libraries are built with TypeScript and have type support out of the box.
By default, Airplane Views are initialized using TypeScript (
.tsx
). Running airplane init
will:- Search for a
tsconfig.json
file in your current directory. If it does not exist, we will generate a defaulttsconfig.json
for you in your current directory. You can change the configuration to suit your needs. - Search your
package.json
for thetypescript
dependency. If TypeScript is not installed, we will install the latest version.
While we provide a
tsconfig.json
file to enable TypeScript code editor support, we currently do
not run tsc
when building your view. This means that type errors will not stop your view from
being deployed.Views supports a number of recommended TypeScript patterns to improve type safety.
Component state
We recommend using Generics to keep
the component state type-safe.
In the following example, we tell
useComponentState
that the component it is registered with is a
table. This automatically types state fields such as selectedRow
while erroring out on fields that
don't exist on the table state such as value
.tsxCopied1const { id, selectedRow } = useComponentState<TableState>();2// The following line would error since `value` does not exist on `TableState`.3// const { id, value } = useComponentState<TableState>();4return (5<Stack>6<Table id={id} columns={columns} data={data} rowSelection="single" />7{selectedRow && <Text>{`Selected ${selectedRow.name}`}</Text>}8</Stack>9);
Most of our examples do not use types for brevity, but we strongly recommend using types throughout
your view!
Task backed components
All Task backed components take
Generics that type the parameters
and output of the task.
In the following example, we've typed the parameters and output of the task
list_animals
that
backs the Select
component.tsxCopied1{/* The task `list_cat_breeds` has parameters of type `{ filter: string }` and output of type string[] */}2<Select<{ filter: string }, string[]>3id={searchAnimals.id}4task={{5slug: "list_cat_breeds",6params: { filter: "" },7// This would cause a type error.8// params: { key: "value" },9}}10// `cats` is of type string[]11outputTransform={(cats) => cats.map((cat) => cat.toUpperCase())}12placeholder="Select a cat breed"13/>