Dynamic Options RPC
Mostly used with select parameter or a search button.
Syntax of RPC output
In order to correctly show a response from your remote procedure, the output
section of response
must contain label
and value
.
"response": {
"limit": 500,
"iterate": "{{body.users}}",
"output": {
"label": "{{item.name}}",
"value": "{{item.id}}",
"default": true
}
}
Select parameter
Select parameter with RPC options
Select parameter with RPC options can be used, when the API doesn't support search.
[
{
"name": "status",
"type": "select",
"options": "rpc://NameOfMyRemoteProcedure",
"label": "Status"
}
]
Filtering options in RPC
If your RPC returns unwanted items, you can filter them out by using the iterate
directive together with the container
and condition
objects.
This approach is only recommended when the filtering of unwanted items is not supported on the API side.
...
"response": {
"iterate":{
"container": "{{body.data}}",
"condition": "{{item.type = 'contact'}}"
},
"output": {
"label": "{{item.name}}",
"value": "{{item.id}}"
}
...
Select parameter with nested RPCs
If your parameters are dependent on each other. The most common example would be dynamically selecting a file. To do it user would select an Account -> Folder -> File. Meaning RPC would require a value of the previous RPC.
Luckily, it is possible to nest RPCs under each other on Make. Here is an abstract example of how it would look inside a module's mappable parameters and RPC's communication.
Don't forget to put all your options to store
property inside options
. Without it nested
will not work.
[
{
"name": "parameter_1",
"type": "select",
"label": "Parameter 1",
"required": true,
"mappable": false,
"options": {
"store": "rpc://exampleRpc1", //proper usage of options in this case
"nested": [
{
"name": "parameter_2",
"type": "select",
"label": "Parameter 2",
"required": true,
"mappable": false,
"options": {
"store": "rpc://exampleRpc2", //don't forget to store your options
"nested": [
"name": "parameter_3",
"type": "select",
"label": "Parameter 3",
"required": true,
"mappable": false,
"options": "rpc://exampleRpc3"
//you are not using "nested" after it
//-> there's no need to "store" options
]
}
}
]
}
}
]
But you're not restricted to using inherited parameters in qs only. In the example below, the nested RPCs obtain a value from the parent's RPC and it is passed to the nested RPC in URL.
Structure is Workspace > Space > Folder
.
[
{
"name": "workspace_id",
"label": "Workspace",
"type": "select",
"required": true,
"mappable": false,
"options": {
"store": "rpc://getWorkspaces",
"nested": [
{
"name": "space_id",
"type": "select",
"label": "Space",
"mappable": false,
"required": true,
"options": {
"store": "rpc://getSpaces",
"nested": [
{
"name": "folder_id",
"label": "Folder",
"type": "select",
"options": "rpc://getfolders",
"required": true
}
]
}
}
]
}
}
]
Select files or folders
Folder, FileSearch button
When the API endpoint supports searching or has a search endpoint, you can implement a search button with confidence.
Search button for a query
{
"name": "authorID",
"type": "text",
"rpc": {
"label": "Search Author",
"url": "rpc://getUser",
"parameters": [
{
"name": "email",
"label": "Author Email",
"help": "Enter author's email on whose behalf the comment should be created. E.g. yours.",
"type": "text"
}
]
},
"label": "Author ID",
"required": true
}
]
Search button with nested RPCs
[
{
"label": "Comment ID",
"name": "id",
"type": "text",
"required": true,
"rpc": {
"label": "Search Comments",
"url": "rpc://getComments",
"parameters": [
{
"name": "id",
"label": "Board ID",
"type": "select",
"mode": "edit",
"options": {
"store": "rpc://listBoards"
},
"nested": [
{
"name": "postId",
"label": "Post ID",
"type": "select",
"options": {
"store": "rpc://listPostsbyBoard"
},
"required": true
}
]
}
]
}
}
]
Advanced search button
Sometimes, it is worth implementing an advanced search (if API does have such endpoints available), which allows a user to enter as many conditions as possible, in order to find the particular record to work with.

Reusable options in a select
Sometimes, it is better to keep the list of available options outside of mappable parameters code. To keep the code readability or use the same piece of code multiple times (like a reusable component).
In this case, we can create a "fake" RPC, where we manually define the list of available options which will be returned in the RPC's output.

Send query to RPC
Sometimes, you can use one general RPC instead of multiple similar RPC with different qs
parameters.
Example: You have one general search endpoint, which requires to specify the type of the search companies
or contacts
.
Instead of creating separate RPCs or hidden parameters inside each module, where the RPC is used. You can send all needed parameters as a query to the RPC.
Example: rpc://yourRPC**?type=contact&active=true**\
[
{
"label": "Option",
"name": "option",
"type": "select",
"options": "rpc://yourRPC?type=contact&active=true"
}
]
Sending an array to RPC
You can send an array to an RPC.
[
{
"name": "options",
"type": "select",
"label": "Options",
"options": "rpc://passArrayToRPC?buttonTypes=a&buttonTypes=b&buttonTypes=c",
"required": true
}
]
Last updated