Logs

Use the Logs tab to see what is happening in your app while you build or preview.

Opening logs while editing

1. Open the Interface tab
2. Click the Debug icon in the left sidebar
3. Open the Logs tab

Opening logs while previewing

1. Click Preview in the top bar
2. Click the Debug button in the top bar to show the navigator
3. Open the Logs tab

In the example above, you can see what happens when you open a project in the WeWeb editor:

• The application is started,
• Table views start being fetched,
• The authenticated user value is set,
• Data from table views are fetched, and so on.

The Logs tab is helpful:

• To understand what's happening in a workflow that is not behaving as expected, and
• To improve the UX and performance of a page by looking at what happens when the user arrives on the page.

Workflow debugging

When you are working with workflows, it can be helpful to look at the logs of what's happening when you execute the workflow:

In the example above, we can see that:

• Our backend returned an error,
• The error was caused by a user trying to login with invalid credentials,
• The workflow moved on to the error branch as a result, and
• Started going through the actions in the error branch.

TIP

Before testing a workflow, try clearing the logs to get a clean view of what is happening:

UX and performance audit

When you develop an app, things can start getting complex quickly.

To scale your projects, audit the UX and performance of your pages on a regular basis.

For example, use the Logs tab to check that:

• Only essential table views are fetched on page load, and
• Variables are updated in the order you would expect.

Example 1 - flow of actions

If a displayError variable is updated before an errorMessage variable, you might see an unwanted blink before the text of the errorMessage is updated.

Changing the order of these actions will greatly improve the experience of your users.

Example 2 - table views fetched

On one page, we couldn't figure out why the list of jobs always appeared as empty on page load, only to be populated when the user interacted with filters on the page.

It turns out we were fetching an old table view on page load (jobs instead of jobs_):

The jobs_ table view was only fetched On change when the user interacted with a filter on the page.

After identifying the problem, we were able to get rid of the old table view and optimize the loading of the jobs_ table view.