Let's take another look at the example Directive:
- type: request
- fn: modify-url
- fn: helloworld-rs
- fn: fetch-test
step, its function results gets stored in the request
state is an ephemeral set of key/value pairs
created for each request. State is used to pass values between
functions, since they are completely isolated and unaware of one another.
modify-url function for example takes the request body
(in this case, a URL), and modifies it (by adding
/suborbital to it).
The second step (
fetch-test) takes that modified URL and
makes an HTTP request to fetch it.
There are two clauses,
with that make working with
request state easier.
as will assign the value returned by a function to a particular name in state.
In the above example,
helloworld-rs is saved into state as
You can think of this just like storing a value into a variable!
For example, the request state after the first step will look like this:
"hello": "hello github.com"
with allows the developer to pass a "desired state" into a given function.
Rather than passing the entire state with the existing keys, the developer
can optionally define a custom state by choosing aliases for some or all of
the keys available in request state. This is just like choosing parameter
values to pass into function arguments!
For example, the
fetch-test function above will recieve a state object
that looks like this:
"logme": "hello github.com"
As outlined in the Directive page,
subo will automatically validate your Directive,
including validating that you're not accessing keys that don't exist in state.