Custom Condition

Triggers your after-action on any arbitrary condition.

The after-action will run as soon as the condition evaluates to true.

Custom can be used for a plethora of things, from setting up access control to triggering requests based on a query parameter.

The possibilities are infinite.

How it works

The condition field creates a boolean context. This means that which means that whatever you return from the function editor will be evaluated as either true or false.

For example, let's say we want to trigger a request only if the user has a code parameter in the URL, we could set our condition up like this:

(c, f, i, n, r, v, e, t) => {
  return n.parameter.code;
};

This means that the condition will evaluate to false most of the time, but if the parameter is present, it will evaluate to true.

To truly understand the condition field, it's important to know the difference between truthy and falsy values.

Custom conditions are being evaluated as soon as the page starts loading. But because the condition field is reactive, it will be re-evaluated if any of the dependencies change.

Access control

Access control is a perfect use case for Custom conditions for two reasons:

• Flexibility — we can write any conditional logic we want
• Performance — the condition gets evaluated as soon as the page starts loading

To set up access control, all we need to do is redirect unauthorized users to the login page.

So no matter how simple or complex our logic is, this part will always stay the same.

There is a condition and a redirect.

Simple access control

The simplest and most common access control setup is checking whether a user is on a protected page, and if they're logged in.

So we need to create a get_user request and trigger it as soon as the page starts loading or we can use another custom condition for triggering the request.

Then we're going to configure our access control in 3 simple steps:

1. In our Custom condition, we are going to check if the user is on a protected page i.e.:

(c, f, i, n, r, v, e, t) => {
  return n.path === '/dashboard'; //[!code focus]
};

2. Next, we're going to set up a redirect to our login page:

(c, f, i, n, r, v, e, t) => {
  return '/login'; //[!code focus]
};

3. Finally, we're going to check the Conditional? checkbox on our redirect:

(c, f, i, n, r, v, e, t) => {
  return r.get_user.hasRequested && !r.get_user.ok; //[!code focus]
};

r.get_user.hasRequested checks whether the request is finished, and !r.get_user.ok returns true if the request fails.

That's it.

If your auth provider requires you to send a token in your request, as is the case with Xano, then we can check whether the user has the cookie.

4. Optional — Check if the user has a cookie containing the auth token:

(c, f, i, n, r, v, e, t) => {
  if (!c.token) return true; //[!code focus]
  return r.get_user.hasRequested && !r.get_user.ok; //[!code focus]
};

This way, you don't even have to run r.get_user. Instead, you redirect the user immediately if they don't have a token stored in the cookie.

Note that in this case, you would also use c.token as a condition to trigger the get_user request.

Protecting multiple pages

In the examples above, we were only protecting the /dashboard page.

But, what if we have multiple pages?

One option is to use the OR operator:

(c, f, i, n, r, v, e, t) => {
  return n.path === '/dashboard' || n.path === '/settings'; //[!code focus]
};

This is okay if our app has only two pages, but as you can imagine conditionals would look messy if we would have 5 or more pages.

A much better approach is to put all of our protected pages into a folder i.e. /app/dashboard and /app/settings.

This way, we can check whether the URL path starts with the folder name:

(c, f, i, n, r, v, e, t) => {
  return n.path.startsWith('/app'); //[!code focus]
};

This Custom condition action will automatically run on every page that we ever add to our app folder.

Complex access control

What if our app has more than one role?

What if we have an admin dashboard, that only admins can access, and a customer dashboard that only customers can access?

The easiest way to set this up is to have two separate folders like we showed above:

• /app/admin/home
• /app/customer/home

Then we can create a condition like this:

(c, f, i, n, r, v, e, t) => {
  return n.path.startsWith('/app/admin') || n.path.startsWith('/app/customer');
};

Now we can create three conditional redirects in the after-action section:

1. Redirect unauthorized users back to the login page
2. If an admin tries to access the customer dashboard, we'll redirect them to the admin dashboard
3. Redirect customers to the customer dashboard

So our first redirect would lead to the /login page, and it would have the following condition:

(c, f, i, n, r, v, e, t) => {
  return r.get_user.hasRequested && !r.get_user.ok; //[!code focus]
};

Our second redirect would lead to /app/admin/home, and the condition would look like this:

(c, f, i, n, r, v, e, t) => {
  return r.get_user.hasRequested && r.get_user.is_admin; //if the user is an admin, they will be redirected
};

And our third redirect would lead to /app/customer/home, and the condition would be the opposite of our previous one:

(c, f, i, n, r, v, e, t) => {
  return r.get_user.hasRequested && !r.get_user.is_admin; //if the user is NOT an admin, they will be redirected to the customer page
};

Alternative access control approach

Since Wized offers a lot of flexibility, we can build the same logic in many different ways.

An alternative approach would be to use the Request finishes action and place our redirects there. Both approaches work equally well.