Data in helps you get data from an external source, and use that data in your web app. In this panel, you can build requests, and change, sort or filter incoming data.
In this panel, we can get data "in" from an external source and use that data in our web app. We can build requests, change, filter, or sort incoming data.
In other words, the Data In panel lets you create, manage, and organize all of your apps' GET requests.
Before we can start using data in, we have to connect to an app from which we're going to get data.
Once that's done, we can set up our first request.
In the upper right corner of the panel, click on the new request button.
This will open the request modal.
This button will open a sub-panel where you can name your request, and choose the source of your data.
Depending on the source of data, you might be using a built-in integration or a custom REST API.
With built-in integrations, all you have to do is select the right options from the dropdowns. The content of the dropdown might vary based on the integration you're using.
On this image, you can see the options for Airtable. You can choose to which base you'd like to connect, and whether you want to get a single item (record) or a list of items.
Getting data from a Rest API can be a little tricky for non-developers.
You can find a list of different integrations here. Note that these integration walkthroughs are managed by the community. The examples might be inaccurate or outdated.
Each Rest API can have a unique headers or query parameters which you need to send to get a response.
Yet, most Rest API's have these two things in common.
They need an endpoint, and a form of authentication. Too see which fields you need to make a request, check out the official documentation of the API.
After you specified an endpoint, you need to add relevant information to the request. You can do that in the header or in the query parameters.
Here, you can see two different examples of Rest API requests.
In this example, we're getting categories from the Zendesk API.
This request is built using key-value pairs in the header.
You can see that the key of the header is set to Authorization, and the value is set to a text field with the following string: firstname.lastname@example.org/token:/YOUR-API-KEY.
Here, we're getting the current weather for a city, using the open-weather API. This request is built using key-value pairs in the query parameters. You can see that the following key-value pairs are required:
- appid="API KEY"
You might have noticed that the name of the city needs to be a dynamic value.
In this case, the value is going to be set to the whatever is typed into our text field.
This means that the end user of our weather widget can type in any city they like.
This project is available as a free cloneable for you to inspect and play with.
Filtering, sorting and limiting data
Once you built a request, you can choose to filter, sort or limit incoming data.
When setting up a filter, you need to set up two fields. The filter trigger and the filter condition.
The filter trigger determines when the filter is active. For example, you can to activate a filter only when a button is toggled.
The filter will be active when the value of this field evaluates to true.
The filter condition determines the filtering logic. For example, if an option A is selected, you want to show only items starting with the word A.
The sorting modal consists of three fields. The sorting trigger, sort by field and sorting direction field.
The sorting trigger determines under which condition the sorting is active. Sorting will be active only when this condition evaluates to true.
The sort by field allows you to chose which field will be used for sorting items.
Sorting direction determines whether the items should be sorted in ascending (A-Z) or descending (Z-A) order.
The limit modal allows you to limit the number of items that are going to be fetched. For example, you can choose to get only the first three items from a 100.
No matter if you're sending data out or in, each request needs to have some sort of trigger. Otherwise it will never get executed.
In this panel you can set the request trigger to execute the request:
- On page load
- After another request
- After a condition evaluates to true
Note: You can also start a request after an action happened on your site. For example if a user clicks somewhere, fills an input or if a form is submitted.
Action triggers are described in more detail on this page.
On page load
The on load trigger will execute the request as soon as the page is loaded. This is useful if you need data from a request immediately.
As soon as this request was executed, you can start using the response data. You can either render data from that request on your page or use that data in another request.
Use the on load trigger if you need the data as soon as the page finishes loading.
After another request
This allows you to sort the order of your requests. For example if you need data from a request before you can execute another request, then this feature comes in really handy.
You can select which requests need to finish executing before you can trigger the next one.
The conditional trigger will get fired as soon as the conditional statement evaluates to true.
This trigger is useful if you have a more advanced use case, which is not covered with the other requests.
For example, you might need several conditions to evaluate to true before a request can be made.
In this case, we’re checking if the user has been loaded, and if she has filled out an input. condition: (user.id && input[name])
This request will only be triggered after both conditions became true.
It let's you choose what happens after the request.
You can choose any of the following options:
- Trigger another request
- Set Cookie
- Set Variable
- Navigate to another page
Gives you an overview of the request including the request trigger, request name, and the actions in which the request is used.
Here you can see all the fields which you received.
Note that if the response is an array, only the first item's values will be listed here.
These response values can be used in many ways including:
- Rendering lists on the page
- Replacing content on your site
- Creating conditional logic
- Computing values using logic
But the response values are not the only values that you can use to build your app's logic. You can also use the request state.
Every request has these two dimensions:
- In progress/Completed
You can use these four states inside your application in the same way you would use any other response value.
If a response value needs to be changed before it can be used inside of your application, you can do that with computed values.
Logic in Wized is like Formulas in Airtable or Excel.
You can take any value from the response and mutate it. You can learn more about Logic on this page.