WeWeb Conditional Visibility: Show, Hide, and Conditional Rendering

Before adding any conditional visibility, decide which method fits your use case. Method 1 — CSS display binding: the element is always in the DOM (rendered in HTML), but its display CSS property is toggled between 'flex'/'block' and 'none'. The element renders and takes up JavaScript memory even when invisible. Use this for: elements that toggle frequently (e.g., a loading spinner that appears and disappears during data fetching), dropdowns and modals, or elements where you need to preserve their internal state (input values, scroll position) while they are hidden. Method 2 — Conditional Rendering: the element is completely removed from the DOM when the condition is false. The element does not render at all, saving memory and rendering time. Use this for: large sections users rarely see (e.g., an admin panel visible only to admins), content behind authentication, or content-heavy sections that would slow down initial page load if always rendered.

The simplest conditional visibility pattern uses a Boolean variable. In the WeWeb editor, open the Data panel (database/layer icon in the left navigation bar) → click Variables → click + New. In the variable creation dialog: name the variable descriptively (e.g., 'isMenuOpen', 'showFilters', 'isLoading'), set the type to Boolean, and set the default value to false. Click Save. This variable will control whether an element is visible. You can toggle it from workflow actions: add a workflow to a button → add the action 'Change variable value' → select your Boolean variable → set the value to the opposite of current (use the formula: !variables['isMenuOpen']). Now your button toggles the visibility state.

CSS display binding is configured in the Styling panel. Select the element you want to show or hide → open the Styling panel → in the Layout section, find the Display property (it shows values like 'flex', 'block', 'grid'). Click the plug icon (🔌) next to the Display property to open the binding formula editor. Write a formula that returns the appropriate display value when visible, or 'none' when hidden. The most common pattern is an if() formula: if(variables['isMenuOpen'], 'flex', 'none'). When your Boolean variable is true, the element gets display:flex and shows. When false, it gets display:none and hides. The element remains in the DOM at all times — you can still access its internal input variables even when hidden.

1// Formula editor — bind to Display property in Styling panel → Layout
2// Basic boolean toggle
3if(variables['isMenuOpen'], 'flex', 'none')
4
5// Show loading state during collection fetch
6if(collections['userData']['isFetching'], 'flex', 'none')
7
8// Show error message when collection fetch fails
9if(variables['hasError'], 'flex', 'none')
10
11// Show element only when collection has data
12if(collections['products']['length'] > 0, 'flex', 'none')
13
14// Show for specific user role (see security note in later step)
15if(variables['currentUser']['role'] === 'admin', 'flex', 'none')

Conditional Rendering is configured in the element Settings panel (not Styling panel). Select the element you want to conditionally render → in the right panel, click the Settings tab (gear icon at the top of the panel, separate from the Styling tab). Scroll down to find the Conditional Rendering section. Click the toggle or the bind icon next to it. The formula editor opens. Write a condition that returns true (element renders) or false (element removed from DOM). Examples: variables['isAuthenticated'] shows content only when logged in; variables['userRole'] === 'admin' shows admin sections. When the condition becomes false, the element and all its children are completely removed from the DOM. This cannot preserve input values — if a form inside a conditionally rendered container is hidden, its input values are lost.

1// Formula editor — bind to Conditional Rendering in element Settings tab
2// Show section only to authenticated users
3variables['isAuthenticated']
4
5// Show admin panel only to admin role
6variables['currentUser']['role'] === 'admin'
7
8// Show empty state when collection has no data and is not loading
9!collections['products']['isFetching'] && collections['products']['length'] === 0
10
11// Show content only when data is fully loaded
12collections['userData']['isFetched'] && !collections['userData']['isFetching']
13
14// Multi-step form: show step 2 only after step 1 is valid
15variables['step1Completed'] === true
16
17// Show notification banner only when there is a message
18variables['notificationMessage'] !== '' && variables['notificationMessage'] !== null

Role-based visibility shows different UI elements to different user roles — admins see admin controls, managers see manager-specific dashboards, and regular users see the standard interface. First, ensure your authentication is set up and user roles are available in a variable or collection. With Supabase Auth: after login, the user's role is typically in the Supabase Auth plugin's user object. Navigate to Plugins → Authentication → your auth plugin → check what user metadata is available. Store the role in a WeWeb variable (e.g., 'currentUserRole') in an 'On app load' or 'On page load' workflow using a 'Change variable value' action. Then bind Conditional Rendering on your role-specific elements to conditions like variables['currentUserRole'] === 'admin'. Stack multiple conditions using && and || operators for complex role logic.

1// Formula for role-based conditional rendering
2// Single role check
3variables['currentUserRole'] === 'admin'
4
5// Multiple roles allowed (OR logic)
6variables['currentUserRole'] === 'admin' || variables['currentUserRole'] === 'manager'
7
8// Exclude a specific role
9variables['currentUserRole'] !== 'trial'
10
11// Array-based roles (user has multiple roles)
12variables['userRoles'].includes('billing')
13
14// Nested condition: authenticated AND specific role
15variables['isAuthenticated'] && variables['currentUserRole'] === 'admin'
16
17// Show 'upgrade' banner only to free users who are logged in
18variables['isAuthenticated'] && variables['subscriptionTier'] === 'free'

WeWeb's breakpoint system allows you to override CSS properties per breakpoint, including the Display property. To make an element visible only on desktop and hidden on mobile: select the element → in the editor top navigation bar, click the breakpoint selector and switch to Mobile (≤767px) → with Mobile breakpoint active, open the Styling panel → find the Display property → bind it or set it to 'none'. Now on mobile, the element is hidden. Switch back to Desktop breakpoint — the Desktop display value is still 'flex' or 'block'. This approach uses CSS media queries under the hood. For a hamburger menu that appears on mobile but not desktop: create the hamburger menu element → on Desktop breakpoint set Display to 'none' → on Mobile breakpoint set Display to 'flex'. This works alongside variable-based bindings — you can layer both.

Collections in WeWeb expose metadata variables that are perfect for conditional visibility: isFetching (boolean, true while data is loading), isFetched (boolean, true after first successful fetch), length (number, count of items), and total (number, total items from server). Use these to build proper loading and empty states. For a loading skeleton: create a skeleton container → bind Conditional Rendering to collections['yourCollection']['isFetching']. For an empty state message: create an empty state component → bind Conditional Rendering to: !collections['yourCollection']['isFetching'] && collections['yourCollection']['length'] === 0. For the actual content list: bind Conditional Rendering to collections['yourCollection']['length'] > 0. These three states cover all data loading scenarios cleanly.

1// Conditional Rendering formulas for collection state UI
2
3// Show skeleton/loading state
4collections['products']['isFetching']
5
6// Show empty state (not loading AND no items)
7!collections['products']['isFetching'] && collections['products']['length'] === 0
8
9// Show actual content (has items)
10collections['products']['length'] > 0
11
12// Show error state (after fetch completed with no data unexpectedly)
13collections['products']['isFetched'] && !collections['products']['isFetching'] && collections['products']['length'] === 0 && variables['hasFetchError']
14
15// Show pagination only when there are more items than shown
16collections['products']['total'] > collections['products']['length']

This is the most important step in this tutorial. Conditional visibility in WeWeb is a UX mechanism, not a security mechanism. When you hide an element using either display binding or conditional rendering, you are changing what the user sees in their browser — but the underlying data may still have been fetched from your backend and is present in the browser's memory or network responses. A technically savvy user can open browser DevTools, inspect network requests, or manipulate the JavaScript context to read data that is 'hidden'. This means: hidden admin interfaces with sensitive data are visible to any determined user. Hiding form fields does not prevent their values from being submitted. Conditional visibility for premium content does not prevent free users from accessing it. The real security layer is always your backend: Supabase RLS policies, Xano endpoint authorization, or REST API authentication. Make sure your backend only returns data the authenticated user is authorized to see — regardless of what the frontend shows or hides.