App Connect

Your guided index of App Connect tours: reactive model, data components, bindings, events/actions, and common workflows — explained visually in Wappler’s panels and pickers.

Back to HTML Editor

App Connect

Your guided index of App Connect tours: reactive model, data components, bindings, events/actions, and common workflows — explained visually in Wappler’s panels and pickers.

Bootstrap 5 dynamic modals (App Connect)

Introduction

This tour introduces Bootstrap 5 modals as reactive UI components inside App Connect. You will look at how the modal is represented in Structure, which bindings and actions control its visibility, and how modal events fit into a larger client-side workflow.

Tour goals

By the end of this tour, you should be able to explain the full modal control loop in Wappler: what opens the modal, what closes it, which state or event drives that change, and where you inspect those bindings and actions in the UI.

Visibility control

Understand whether the modal is driven by direct actions, bound state, or a combination of both.

Event flow

See how modal open and close events can trigger follow-up UI behavior without custom boilerplate.

Inspection points

Know where to select the modal and where its Properties reveal the relevant actions and bindings.

Inspect the modal component and the controls that trigger it

Trace how show and hide behavior is configured in App Connect

Use that mental model to build modal workflows without hand-written DOM code

Where you configure it

Use App Structure to select modal elements and Properties to configure bindings, events, and actions.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Bind modal show/hide state

Trigger modal actions

Handle modal events

Use the Browser component for navigation, online/offline state, viewport, scroll, and history events.

Introduction

This tour positions the Browser component as App Connect’s bridge to client-side browser state. You will review which events and properties it exposes, how those values become usable in bindings, and when it is the right source for navigation, viewport, online status, and history-driven behavior.

Tour goals

The goal is to understand the Browser component as a shared context provider for the page, not just a list of random browser APIs. By the end, you should know which kinds of UI behavior belong here and how to inspect those events and values in Wappler.

Navigation state

Use browser information for redirects, links, history-aware UI, and page-level decisions.

Viewport and status

Read viewport size, scroll position, and online state where responsive or resilient UI needs them.

Event source

Treat browser events as declarative triggers that feed App Connect actions and bindings.

Identify which page behaviors should use Browser component state

Review the events and values the component contributes to App Connect

Connect those values to responsive or navigation-aware UI patterns

Where it shows up

Configure Browser events and state in Properties, and use it as a UI-level source for navigation and viewport data.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Calculator (expressions + toNumber)

Build a small reactive calculator in Wappler and use it to understand expressions, input scope, and why toNumber() is essential before doing numeric math in bindings.

Calculator: reactive expressions

This tour uses a two-input calculator to show how App Connect expressions evaluate in real time. You will inspect the result binding, follow where each value comes from, and see where type conversion prevents string-math bugs.

What you’ll learn

You will learn the whole expression workflow, not just the final formula: which inputs are in scope, how the Data Bindings Picker helps assemble the expression safely, and where to apply toNumber() so the result behaves like real arithmetic.

note: HTML input values are strings by default. Use toNumber() before doing math (A.value.toNumber() + B.value.toNumber()).

Bindings

UI is wired to data with expressions.

Data Bindings Picker

Browse what’s in scope and insert valid expressions into a field.

toNumber()

Convert input strings to numbers before doing math.

Select the result element

Inspect its text binding in Properties

Use the Data Bindings Picker to explore scope + build the expression

Prerequisites

This tour opens a sample App Connect page in Design View. Keep Page Panels (Structure) and Selection Panels (Properties) visible.

Expression: computed result

The result is computed from two inputs. No click action is needed — the expression is reactive.

Result field (auto-selected)

Inspect the result text binding — it shows the computed sum expression. (The result text is selected for you.)

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on Text binding expression and see how it fits into this area.

Text binding expression

This field contains the expression that computes the sum. It uses toNumber() so math works correctly.

note: App Connect input values are strings by default. Use toNumber() before doing math (A.value.toNumber() + B.value.toNumber()).

Inspect it in the Data Bindings Picker

The picker icon opens the Data Bindings Picker so you can explore what’s in scope and see how the expression is built.

tip: Prefer the Data Bindings Picker over typing raw expressions — it keeps your bindings valid.

Use the Data Bindings Picker to select inputs and formatters from a tree and insert them into the binding field.

Inputs in scope

You’ll see the input components and their properties in the tree. Select their value properties to build expressions.

Expression preview

This preview shows the full expression that will be inserted back into the text binding field.

Formatter icon

This icon opens the Data Formatter for advanced formatter chains such as number, currency, date, and text formatting. You can explore that popup in the dedicated Data Formatter tour.

Close Data Bindings Picker

Close the Data Bindings Picker to return to Properties. This step matters because Close Data Bindings Picker is part of Popup Databindingspickup Button Cancel, and understanding that context makes the next action easier to repeat in your own project.

Try it in Preview mode

Switch to Preview mode and change the input values. The result updates immediately.

Switch to Preview mode

Preview mode makes the inputs interactive.

Wait for Preview mode

Wait for the page to finish switching modes.

Change A and B

Type new numbers in A and B. The result updates instantly (no button required).

Return to Edit mode

Switch back to Edit mode to continue learning.

Next steps

You’ve practiced expressions and type conversion. Next, learn the bigger workflow: components, properties, events, and actions.

Pick your next tour

Continue learning App Connect gradually.

Conditional display & repeating lists

Use show/hide/if and repeaters to render UI from data — configured visually in Wappler.

Conditional display & repeating lists

Build reactive UI by showing/hiding sections and repeating elements from a dataset — configured visually in Wappler (no manual code required for the common cases).

Three building blocks

Most dynamic UI on the page comes down to: conditional display, binding text/attributes to data, and repeating UI for lists.

Conditional display

Show/hide/if based on state (toggle, variable, form state).

Bindings

Bind text, attributes, and classes to data using the picker.

Repeaters

Render lists from arrays / Data View / Data Store.

Pick the element in App Structure

Configure dynamic behavior in Properties

Let data drive the UI

Where you’ll work

Select the element in App Structure, then use Properties to configure show/hide/if, repeat, and bindings.

Conditional display (show/hide/if)

Control when an element is visible and whether it exists in the DOM.

Show/Hide toggles visibility

Use show/hide when you want to keep the element in the DOM but toggle visibility based on state (a Toggle, Variable, form state, etc.).

tip: Show/hide is great for UI switches where layout stays stable.

If conditionally renders

Use if when you want the element removed from the DOM when false (often better for performance and for components that should not exist).

important: If removes the element from the DOM when false. Nested bindings and events won’t run because the element isn’t there.

Choosing the right one

Prefer show/hide for simple visibility, and if for expensive UI (repeaters, complex components, large sections).

show/hide = visibility

if = render/unrender

both are declarative (no manual DOM updates)

Binding text and attributes

Connect what users see to your data using bindings (instead of manual string concatenation).

Prefer reactive text binding

When you bind text content, prefer dmx-text (or the text binding option in Properties) for stable updates and less flicker than raw template text.

Reactive updates

Updates automatically when the source data changes.

Formatter-friendly

Use formatters (date/currency/text) directly in the expression.

No manual DOM

Avoids manual DOM manipulation.

Bind attributes/classes/styles visually

Use bindings for attributes like src/href/value and conditional classes/styles. This is how Wappler maps to dmx-bind:* without you writing raw attributes.

tip: Use the binding picker to select the right field/formatter for src/href/value/classes — it’s scope-aware and avoids typos.

Use the picker to avoid typos

When a field supports bindings, use the picker to browse available components and methods in the current scope.

tip: If a binding looks wrong, re-check what’s selected in App Structure — scope is selection-driven.

Repeating lists (repeaters)

Repeat UI from an array, Data View, Data Store, or API result.

Two repeat styles (what they change)

App Connect supports two repeat patterns. In Wappler you’ll pick the one that matches your desired HTML structure.

Repeat the element

The element itself repeats (great for repeating a row/card/list item).

Repeat children

The container stays once, its children repeat (great for a single wrapper like a UL or grid row).

Element-repeat changes the element count

Repeat-children keeps the wrapper stable

Both create a local item scope

Common data sources for repeating

Repeaters can be driven by Arrays, Data Store records, Data View output, or API results. The picker will show you what’s available in scope.

Array items

Data Store records

Data View data (filtered/sorted/paged)

Server Connect data

Scope matters inside a repeat

Inside a repeat, bindings resolve against the current item. Select a repeated element in App Structure to see the right fields in the picker.

tip: If you can’t see a field, ensure you’re selecting the repeated node (not just the parent wrapper).

Conclusion

Next, practice with Data View and events/actions, then learn formatters.

Pick your next tour

Continue learning App Connect.

Contact create and success handoff

Use the real contact add page to see how App Connect combines lookup data, submission state, and the success handoff into the new contact detail page.

Introduction

The contact add page is a useful App Connect example because it starts from an empty form but still depends on live data and clear success state. The page loads client choices, submits a new contact through one form, and turns the insert result into a direct handoff to the new detail page.

Start from the real contact add page and its live lookup field.

See how submission state and insert output stay on the same form.

Follow the success handoff into the new contact detail page.

Page state: lookup data, empty inputs, and submit feedback

The contact add page shows that create forms still need App Connect structure even without an existing record to restore. Client lookup data is loaded first, the form exposes executing and error state, and the insert result becomes the page’s success handoff.

The contact add page starts empty but not unstructured

Start on the real contact add page so the lookup loader, empty form fields, and submission feedback live in one context. The page works because App Connect still owns lookup data and request state even when there is no existing record yet.

The client autocomplete depends on live lookup data

#contact_client binds to sc_clients.data.clients, so the new contact can still be attached to a real client without hard-coded options. The field also accepts query.client_id, which makes preselected client context possible when the page is opened from elsewhere.

The create form exposes request state and insert output

#contact_form posts to /api/contacts/insert, exposes executing and lastError state, and returns insert_contact when the record is created. That output is what lets the page stay declarative about success instead of manually building navigation state.

Success feedback hands off directly to the new detail page

The success alert links to /contact/ plus contact_form.data.insert_contact.identity, so the create flow ends with a concrete destination. That keeps the user oriented because the new record becomes immediately inspectable instead of disappearing behind a generic success message.

Conclusion

The contact create page stays understandable because App Connect makes the create lifecycle explicit. Lookup data arrives before the field needs it, the form exposes request state while saving, and the insert result hands the user straight into the new record.

Load lookup data before expecting a create form to use it.

Keep create-form request state visible while the save is running.

Use insert output to hand off directly into the new record’s next page.

Contact delete confirmation and return handoff

Use the real contact edit page to see how App Connect keeps the destructive delete flow explicit with confirmation, request state, and a return-to-contacts handoff.

Introduction

The contact edit page does something important with destructive actions: it keeps delete separate from normal editing. App Connect makes the delete path legible by giving it its own form, confirmation moment, request state, and a clear route back to the contacts list after success.

Keep delete separate from the richer edit form.

Make the destructive submit state visible while the request runs.

End with a concrete return path instead of a vague success message.

Frontend: the delete path stays explicit

The contact edit page keeps the destructive workflow understandable by separating delete from update. That gives the page room to show the warning, request state, and success/error outcome without overloading the normal edit form.

The edit page shows both the normal edit path and the delete path

Start on the real contact edit page so the two forms are visible together. The page makes a clear distinction between updating the current contact and permanently removing it.

The delete action is its own Server Connect form

#contact_delete has its own action, hidden id input, success state, and error state. That separation matters because destructive work should not disappear inside the richer update form contract.

The submit control makes the destructive moment explicit

The delete button does two practical things before the record disappears: it asks for browser confirmation, and it disables itself while contact_delete.state.executing is true. That gives the user one last check and prevents accidental double submits.

The success state ends with a route back to the contacts list

After a successful delete, the page does not leave the user stranded on a now-invalid record. The success alert exposes a direct return link to /contacts, so the destructive flow ends in a safe list view instead of a broken detail context.

Conclusion

The delete flow feels trustworthy because App Connect gives it a separate surface, an explicit confirmation moment, a visible request state, and a clear way back to the contacts list once the record is gone.

Keep destructive work separate from the normal edit contract.

Expose executing and error/success state where the user makes the decision.

Finish destructive flows with a stable return destination.

Checkbox, autocomplete, and tags on edit forms

Use the Demo Projects HQ contact edit page to see how App Connect restores boolean, autocomplete, and tag-style controls before editing starts.

Introduction

The contact edit page fills a gap that many edit-form examples skip: not every restored control is a plain text box. This page restores a related client in autocomplete, a boolean primary-contact state, and tag-style metadata before the editor makes any changes.

Load the current contact record first.

Restore each control type from that record.

Keep boolean, autocomplete, and tag state as trustworthy as text fields.

The edit form starts from one contact record and one lookup list

sc_contact provides the saved record, and sc_clients supplies the client options that the autocomplete control can resolve against. That pairing is what makes the whole page restorable instead of leaving each control to guess its own state.

Autocomplete must restore a visible relationship, not just an ID

#contact_client shows why relationship fields need more than a hidden value. The stored client_id has to resolve back into a human-readable client option so the editor can confirm the right relationship before making changes.

Boolean state must restore the intended choice, not just a checked box

#contact_primary is the clean boolean example. The page keeps both the hidden fallback value and the checkbox, but the visible control still has to reflect the saved is_primary state before the editor decides whether this contact stays primary.

Tag widgets still need the saved record before editing begins

#contact_tags is a reminder that widget-style controls are still edit fields. The Tagify input has to start from the saved contact tags so the user is refining the existing metadata instead of rebuilding it from memory.

Conclusion

Edit-form restoration is only complete when the less obvious controls are correct too. Autocomplete, checkbox, and tag widgets all need the same reliable source record, or the page quietly stops feeling trustworthy.

Restore relationship controls visibly, not just by hidden IDs.

Treat boolean state as real record state, not a UI afterthought.

Keep tag-style widgets aligned with the saved record before editing begins.

Contact list to detail route handoff

Use the real contacts and contact detail pages to see how App Connect turns a repeated list, route parameter, and detail loader into one continuous record flow.

Introduction

The contacts pages are useful App Connect examples because they turn one continuous data flow into two readable pages. A repeated contacts list links to a route-aware detail page, and the detail page resolves that route value into one loaded record without custom glue code.

Start from the real contacts list and its repeated rows.

Follow the record id into the route-aware contact page.

See how the detail page binds one loaded contact into readable UI.

List page: one dataset feeds the repeated contact rows

The contacts page stays readable because one loader feeds one repeated table. The list does not copy record state around manually; it binds the contacts dataset directly into rows and links.

The contacts page starts from one loaded contacts dataset

Start on the real contacts page so the loader and repeated table stay visible together. The page works because one Server Connect component supplies the contact rows and the UI binds to that shared result instead of duplicating record state.

The repeated rows bind directly to sc_contacts.data.contacts

#contacts_list repeats over sc_contacts.data.contacts, which keeps the list declarative. Each visible row is just a bound view of the contacts dataset, not a separate client-side copy to keep in sync.

Each row link passes record identity through the route

The contact name link binds /contact/ + id, so the selected record identity stays explicit in navigation. That route handoff is what lets the next page reconstruct the same record without hidden browser state.

Detail page: route context becomes one loaded record

The detail page takes over once the selected record id is in the URL. Its Server Connect component resolves that route context into one contact object, and the page binds the object into cards, badges, and follow-up links.

The contact detail page is open

The real contact detail page is now visible, so the route-aware page and its bindings can be inspected in context. This is the page that receives the selected record identity and turns it back into one loaded contact object.

Design view is active for the contact detail page

Switch to Design view before inspecting the route-aware bindings so the next steps can focus on the live page structure instead of editor setup.

The detail page resolves the route value into one contact record

The detail page uses the /contact/:id route and passes the query id into sc_contact, so one selected record becomes one loaded contact object. That is the App Connect handoff from route context to usable page data.

The page binds one contact object into details, badges, and links

The detail page stays readable because the cards, badges, and action links all bind back to sc_contact.data.contact. Client name, primary badge, tags, and edit navigation all come from the same loaded record object.

Conclusion

The contacts flow stays understandable because the handoff is explicit at every stage. The list repeats one dataset, the row link carries the record id in the route, and the detail page reloads that exact record into one bound object.

Keep record identity explicit in navigation.

Let the destination page reload its own detail record from route context.

Bind the detail UI to one authoritative object instead of spreading record state around.

Core concepts (expressions + bindings)

Understand App Connect’s reactive model, expression rules, scoping, and how to use Wappler’s data/action pickers to build bindings visually.

Core concepts

App Connect is declarative and reactive: you declare what the UI should show and when actions should run, and App Connect keeps the page in sync.

Expressions are picker-driven

In Wappler, most dynamic behavior is configured in Properties using bindings and actions. Use the Data Picker and Expression Builder to select data and functions from a tree, so you can build expressions quickly and safely.

Data Picker

Browse available components, data, and methods in a tree and insert them into a field.

Scope

What you can pick depends on what’s selected in App Structure and where you are in the component hierarchy.

Formatters

Use formatters (date/currency/text) directly in bindings to shape values for display.

Data changes → UI updates

Events trigger actions

Expressions stay declarative

Where you work in Wappler

Most App Connect work happens in two places: App Structure (select components) and Properties (configure bindings and events).

Quick walkthrough (one binding + currency)

A quick, low-friction example: bind a single value, then format it as currency. This is the “happy path” for most bindings — fast, safe, and picker-driven.

Pick a single value from scope

In Properties, open the picker for a bindable field (for example Text/Value). Select a single value (not an array), like a product price or variable value. The picker inserts a valid expression for you.

tip: If you only need a simple path (like product.price), picking is faster and avoids typos.

Pick a scalar value, not a list

Let the picker insert correct syntax

Stay within current component scope

Format it as currency

With the value selected, apply a number formatter like formatCurrency() so the UI shows a readable price (e.g. $1,234.56) without changing the underlying data.

note: For one-off formatting, the picker is enough. Use the Data Formatter popup when you want to build longer formatter chains visually.

Chain formatters on the expression

Format at display time

Keep the source value unchanged

When to use the Expression Builder

Use the Visual Expression Builder for logic and conditions (operators, comparisons, grouped rules). It’s still scope-aware, but it’s built for expressions like filters and if conditions rather than simple data paths.

tip: Rule of thumb: Data Bindings Picker for “pick a value”, Expression Builder for “build logic”.

Build conditions and comparisons

Group rules for readability

Use scope-aware picker inputs

Bindings (reactive properties)

A binding connects a property to data. When the data changes, the property updates automatically.

Use the expression picker

When a field supports bindings, Wappler offers a picker so you can select data sources and methods instead of typing everything by hand.

tip: If you’re unsure what’s available, use the picker to explore the current data scope.

Dynamic Attributes ( + )

Not every binding starts as a field. In the Dynamic Attributes section, use the ( + ) button to add new App Connect attributes to the selected element. The list is generated from the component’s HTML rules and filtered by what’s allowed on that element (via each rule’s allowedOn).

tip: If you don’t see a specific attribute, try selecting a different element or inserting the related component first.

Why the ( + ) list changes

The Dynamic Attributes menu is context-aware: selecting a different element changes the list because different HTML_RULES match, and allowedOn decides where each rule can be applied (for example, some rules only allow a Google Maps attribute on a dmx-google-maps element).

Understand scope

What you can bind to depends on what’s in scope (which components exist on the page and where they are in the structure). In Wappler, this is why selecting the correct node in App Structure matters.

Events (run actions)

Events are configured in Properties. You enable an event and choose an action to execute.

Actions are visual, not raw code

Choose an action from the Actions Picker (for example: set a value, insert/update a record, navigate, reload data), then configure its parameters in Properties.

tip: If you can’t find an action, check the selected component and the event type — available actions are context-aware.

Enable an event

Pick an action

Configure parameters in Properties

Modifiers change behavior

Modifiers like prevent/stop/once help you control default browser behavior and event propagation without manual code.

Conclusion

Next, take a hands-on tour or jump straight to collections and filtering.

Pick your next tour

Choose a focused tour based on what you want to build.

Counter (reactivity starter)

A compact App Connect starter in Wappler: a Variable stores state, a button updates it, and a bound text label reflects the new value immediately.

Counter: reactivity in 60 seconds

You will walk through the smallest App Connect feedback loop in Wappler: select the Variable that holds state, inspect the button action that changes it, and confirm how the bound label redraws instantly.

What you’ll learn

By the end, you should be able to explain the whole reactive chain in plain language: where the state lives, which event triggers the update, which action changes the value, and why the UI refreshes without manual DOM code.

State

A Variable holds the count.

Action

A button increments the Variable.

Binding

A text binding shows the value.

Select components in App Structure

Inspect bindings in Properties

Use the Data Picker to explore scope

Where you work

Keep Page Panels (Structure) and Selection Panels (Properties) visible.

State: a Variable

A Variable stores a value you can bind to and update through actions.

Variable component

The Variable stores the counter state. We’ll select it to review its properties. This step matters because Variable component is part of the Structure panel, and understanding that context makes the next action easier to repeat in your own project.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on Review the component ID and see how it fits into this area.

Review the component ID

The ID is how you reference the Variable in bindings and actions (for example: counter.value, counter.setValue(…)).

Review the initial value

For Variables, prefer binding the initial value as an expression (dmx-bind:value=“0”) so it’s a real number, not an HTML string. Convert toNumber() mainly when values come from HTML inputs where the user types.

tip: App Connect expressions are declarative. Don’t use JavaScript callbacks/functions inside dmx-* expressions.

Action: increment on click

Events trigger actions. The action updates state, and bindings react automatically.

Increment button

This button increments the counter by running the Click action. We’ll select it to inspect the event.

Inspect the Click event

The Click event row in Properties is where this button’s event action is configured. Here it runs an action list that calls counter.setValue(…) to update state, and bindings update the UI automatically.

tip: Open the Actions Picker to explore the action list and configure action inputs instead of hand-typing expressions.

Actions Picker

The Actions Picker has opened from the Click event row. This is the popup where you inspect the event action list before focusing on its specific areas.

tip: Use the Actions Picker to add actions and fill their inputs safely, without hand-typing long expressions.

The Actions Picker lets you choose actions (like setValue) and builds the Click event’s action list for you.

Use the Available Actions area to browse categories, search, and use the quick navigation controls along the top to move through long action lists faster. This step matters because this is the main browsing surface of the Actions Picker before you focus on the selected action list and action inputs.

Selected Actions (center)

This list is what runs when the Click event fires. Order matters.

Action Properties (right)

Select an action in the list to configure its inputs here (for example, the value you pass into setValue(…)). This step matters because Action Properties (right) is part of Popup Actionspickup Layout Layout Panel Preview, and understanding that context makes the next action easier to repeat in your own project.

Close Actions Picker

Close the Actions Picker to return to Properties. Use Cancel or the window close button to return to the Properties panel.

Binding: show the value

Bindings connect UI properties to data. When data changes, the UI updates automatically.

Counter display

This label is bound to the counter value. We’ll select it to inspect its text binding expression.

Text binding expression

This field contains the expression that fills the text (counter.value). Click the picker icon to inspect it with the Data Picker.

tip: Use the Data Picker to avoid typos and stay within the correct scope.

The Data Bindings Picker shows what’s in scope and lets you insert valid expressions into the field.

Data tree (scope browser)

Expand nodes to browse components and their properties. Selecting an item builds the expression for you.

Expression preview

This preview shows the final expression that will be inserted back into the field.

Close Data Picker

Close the Data Picker to return to Properties. This step matters because Close Data Picker is part of Popup Databindingspickup Button Cancel, and understanding that context makes the next action easier to repeat in your own project.

See it live

Switch to Preview mode and click the button to watch the UI update.

Switch to Preview mode

Preview mode makes the page interactive so you can use it like a user would.

Click Increment

Click the Increment button a few times. The Variable updates, and the bound text updates instantly.

Return to Edit mode

Switch back to Edit mode to continue learning.

Next steps

Now that you’ve seen the simplest reactive loop, continue with a slightly richer example or the full App Connect overview.

Pick your next tour

Continue learning App Connect gradually.

Data Bindings Picker (scope + Design/Code)

Deep dive into Wappler’s Data Bindings Picker and Visual Expression Builder: scope tree, Design vs Code view editing, preview, and inserting expressions safely.

Introduction

This tour uses a dedicated App Connect tour page so you can explore bindings and pickers safely. You’ll learn how Wappler builds expressions visually, how scope affects what you can pick, and how Design vs Code view affects how you edit bindings.

What you’ll learn

Wappler’s binding workflow is picker-driven: select data from a tree and let Wappler generate the correct expression for you.

Scope-aware

The picker only shows what’s in scope.

Safe expressions

Picking avoids typos and invalid paths.

Formatting hook

When you’re ready to format values, continue with the Data Formatter tour (this tour focuses on bindings + Expression Builder).

Select the right node in App Structure

Open the picker from Properties

Use the tree + preview to build expressions

Bound element (auto-selected)

This step auto-selects a repeating element in Design View so the picker has real data in scope.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on Data Bindings Picker and see how it fits into this area.

Data Bindings Picker

The picker icon opens the Data Bindings Picker for the Repeat expression. This step matters because Data Bindings Picker is part of Selection Panels Properties Repeatexpression, and understanding that context makes the next action easier to repeat in your own project.

tip: When in doubt, open the picker: it shows only valid items for the current scope.

Data Bindings Picker (scope browser)

The Data Bindings Picker shows data/components/methods available in the current scope. Selecting an item builds the correct expression and previews what will be inserted back into Properties.

This popup is the central workflow for building bindings safely. Use it whenever you see a picker icon next to a bindable field.

Scope tree

Expand nodes to browse components and their data. This is your current scope — it changes depending on what’s selected in App Structure.

Use the toolbar to search and navigate large scopes quickly (expand/collapse, search, etc.).

Preview expression

This preview shows the full expression that will be inserted into the originating field when you pick items from the tree.

Depending on the picker mode, the preview area can offer helper controls for editing or refining the expression before inserting it.

Design vs Code view (editing mode)

When a binding supports mixed content, Wappler offers two editing modes. Design view helps you visually build a combined value (text + picked expressions) without worrying about quoting/escaping. Code view shows the raw expression/text, so you can fine-tune it directly when needed. You can switch between them, but it’s usually safest to stay in Design view and let Wappler generate valid syntax.

Close the Data Bindings Picker

Close the picker to return to Properties. This step matters because Close the Data Bindings Picker is part of Popup Databindingspickup Button Cancel, and understanding that context makes the next action easier to repeat in your own project.

Visual Expression Builder (logic + operators)

Some properties use the Visual Expression Builder. It’s still scope-aware, but focused on building logic (operators, conditions) rather than just picking a data path.

Component with filter (auto-selected)

This step selects a Data View so you can see the Expression Builder flow.

Visual Expression Builder

The Data View Filter picker opens the Visual Expression Builder so you can build conditions visually.

This popup helps you build valid expressions with operators and grouped conditions, while staying in the correct scope.

Scope tree

Just like the Data Bindings Picker, the Expression Builder exposes scope. Use it to pick data sources and methods while constructing logic.

Preview expression

This preview shows the full expression that will be inserted back into the originating field when you apply/close the popup.

Design vs Code view (editing mode)

If the expression builder shows mixed content, you can switch between Design (visual) and Code (raw) editing. Design view is preferred because Wappler handles quoting/escaping and keeps the expression valid; Code view is there when you need to tweak the raw expression.

Conclusion

You’ve seen how Wappler builds bindings safely with pickers, how scope affects what’s available, and how Design vs Code view lets you choose between visual editing and raw expression editing.

Pick your next tour

Continue with a deeper formatting tour or review formatters at a high level.

Data components (Variable, Array, Toggle)

Explore App Connect data components—Variable, Array, and Toggle—and the key Properties you’ll configure for each.

Data components

This tour introduces the small set of App Connect components that create client-side state before the rest of the page consumes it. You will compare Variable, Array, and Toggle as foundational building blocks, then connect each choice to the bindings, actions, and UI patterns it supports best.

Which one should you use?

This tour helps you choose the right state primitive before you start wiring the page. Instead of memorizing three components separately, you will learn the decision rule for each one, how they appear in Structure, and how their values are typically consumed by bindings and actions.

Variable

One value (can be text/number/object/array).

Array

A list of items (often used as a simple collection).

Toggle

A boolean on/off state (great for UI switches).

Hold state

Bind UI to state

Update state via actions

Where you configure these

Insert the component via App Structure, then configure ID + bindings in Properties.

Variable (dmx-value)

A Variable stores a single value you can reference in bindings and set via actions.

ID

The ID is how you reference the component in bindings and action pickers. This step matters because ID is part of Selection Panels Properties Theid, and understanding that context makes the next action easier to repeat in your own project.

Value

Value is the initial data stored in the Variable. Use the expression picker to select data and formatters.

Common action: setValue

Most pages use an event (like click) to run setValue on a Variable. This keeps state changes visual and consistent.

Update a Variable at runtime

Increment/decrement numeric values

Toggle booleans or set from expressions

Use actions to drive UI state

Array (dmx-array)

Array stores a list of items and offers actions to add/remove/update list entries.

ID

Name it for what it holds (for example: products, tags, steps). This step matters because ID is part of Selection Panels Properties Theid, and understanding that context makes the next action easier to repeat in your own project.

Items

Items defines the initial list (binding). In practice, Arrays are often filled/changed by actions.

tip: If you need filtering, sorting, or paging, use a Data View on top of your source data.

Toggle (dmx-toggle)

Toggle holds a boolean state. It’s ideal for showing/hiding UI or enabling/disabling actions.

ID

Set a clear ID so it’s obvious what the toggle represents (for example: showDetails). This step matters because ID is part of Selection Panels Properties Theid, and understanding that context makes the next action easier to repeat in your own project.

Checked

Checked controls the initial on/off state. You can bind it to other data, or set it through actions.

Conclusion

Next, learn collections and traversal: Data Store and Data View.

Pick your next tour

Choose a focused tour based on what you want to build.

Data View (filter/sort/page)

Use Data View to filter, sort, and paginate any dataset without mutating the original source.

Data View

This tour frames Data View as the layer between raw collections and the version of that data the user actually sees. You will look at how search, sort, and paging reshape a dataset declaratively while leaving the original source untouched for other components or workflows.

Why Data View matters

It keeps your original collection stable while letting UI controls (search/sort/paging) reshape what’s displayed.

Source data stays untouched

Filtering + sorting are declarative

Paging is built-in

Where you’ll use it

You’ll usually combine Data View with UI controls (search input, selects, sort buttons, paging). Those controls update the view, and anything repeating the view updates instantly.

Search/filter inputs → update Filter

Sort controls → update Sort On / Direction

Paging controls → update Page / Page Size

Repeats/tables → bind to data_view.data

Core Properties

These are the properties you’ll configure most often.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on ID and see how it fits into this area.

ID

Name it so it’s obvious what the view represents. This step matters because ID is part of Selection Panels Properties Dataviewid, and understanding that context makes the next action easier to repeat in your own project.

Source

The source field controls which dataset the Data View reads (array, Data Store items, API results, etc.).

tip: The Data Bindings Picker only shows items in the current scope, so it’s hard to pick something invalid.

The Data Bindings Picker opens as a popup. Use it to browse available data and insert a valid source expression.

Data hierarchy tree

Expand nodes to find the list you want to view. Selecting an item inserts it into the Source field.

Selection preview

This preview shows the expression that will be inserted into the Source field.

Close Data Bindings Picker

Filter

Define a filter expression for search and user-controlled filtering. Click the picker icon to open the Visual Expression Builder.

The Visual Expression Builder opens as a popup. It helps you build valid expressions with operators, functions, and data sources in scope.

Query builder

This area lets you compose filter logic visually (fields, operators, and values) instead of typing everything manually.

Rule parts (optional)

Each rule is composed of a Field, an Operator, and a Value. Use pickers to bind values from scope instead of typing constants.

AND / OR groups (optional)

Use groups to combine multiple rules with AND/OR for more complex filters. This step matters because AND / OR groups (optional) is part of Popup Expressionbindingspickup Query, and understanding that context makes the next action easier to repeat in your own project.

Expression preview

This field shows the final expression that will be inserted back into Properties when you apply the popup.

Formatter icon

This icon opens the Data Formatter for advanced formatter chains inside the filter expression. You can explore that popup in the dedicated Data Formatter tour.

Close Visual Expression Builder

Close the Visual Expression Builder to return to Properties. This step matters because Close Visual Expression Builder is part of Popup Expressionbindingspickup Button Cancel, and understanding that context makes the next action easier to repeat in your own project.

Sort

Configure sort field and direction. This step matters because Sort is part of Selection Panels Properties Dataviewsorton, and understanding that context makes the next action easier to repeat in your own project.

Sort direction

The sort direction controls ascending vs descending ordering. This step matters because Sort direction is part of Selection Panels Properties Dataviewsortdir, and understanding that context makes the next action easier to repeat in your own project.

Paging

Use Page and Page Size to paginate displayed results. This step matters because Paging is part of Selection Panels Properties Dataviewpage, and understanding that context makes the next action easier to repeat in your own project.

Page size

How many items to show per page. This step matters because Page size is part of Selection Panels Properties Dataviewpagesize, and understanding that context makes the next action easier to repeat in your own project.

Conclusion

Next, connect UI events (click/submit/keyup) to actions.

Pick your next tour

Continue with events and actions.

Demo walkthrough: Dynamic Real Estate Site

Guided walkthrough of the renewed Real Estate demo: Server Connect APIs, App Connect Data Views, filters, map, and repeated listings.

Open the renewed demo project

We start from the live Demo Dynamic Real Estate Site so the walkthrough tracks the real Node.js and SQLite sample, not an older static snapshot.

Projects Manager is shown

Projects Manager appears automatically so the walkthrough begins from the same project-switching workflow users use elsewhere in Wappler.

Demo project becomes current

The renewed sample becomes the active project so the walkthrough can follow the live EJS pages, Server Connect APIs, and App Connect surfaces that now power the demo.

Home page opens

The renewed home page lives at views/index.ejs. It uses Server Connect to load listing data and App Connect to shape that data into featured home-page UI.

Home page is active in Design View

The home page is now the active HTML editor surface, so the Structure and Properties panels can reflect the live page context correctly.

Home page data flow

On the home page, Server Connect loads the catalog and App Connect reshapes it into a featured subset for cards and sliders.

Dashboard summary API

sc_summary loads the high-level counts shown in the hero statistics row, so the headline metrics come from real server data instead of fixed markup.

Featured listings API

sc_featured calls /api/listings/list. This is the raw server collection the page uses before App Connect filters it down for the home-page presentation.

Featured Data View

featured_listings is the shaping layer. It reads sc_featured.data.listings, keeps only featured records, and sorts them before the UI repeats them.

Featured section in Design View

This section is the practical result of that data flow: the server collection feeds the Data View, and the Data View feeds the cards and slider users actually see.

Repeated featured cards

The repeat region turns the shaped featured_listings.data collection into individual property cards, keeping the UI declarative and driven by live data.

Listings page filters and outputs

The listings page shows the full pattern more clearly: a server collection feeds a Data View, the Data View reacts to filters, and multiple outputs stay synchronized.

Listings page opens

views/listings.ejs is where the renewed demo makes the filter pipeline explicit. This page shows how App Connect reshapes live API data in place.

Listings API source

sc_listings loads the full listing collection from /api/listings/list. It is the authoritative source collection for this page.

Listings Data View

listing_results is the page’s shaping layer. It reads the API result, filters against the UI controls, and sorts using the current sort-direction input.

Filter controls surface

These controls are the inputs the Data View reacts to. App Connect does not replace the UI here; it connects the UI values directly into the filter expression.

Minimum beds control

inp_beds is one of the live inputs inside the filter expression. Changing it narrows the results without needing another request.

Sort direction control

inp_sort_dir shows that the same Data View also owns sorting, not just filtering. The shaped collection updates and every bound output follows it.

Map bound to the filtered view

The Leaflet map reads the filtered listing_results.data collection directly, so the map and the card list stay synchronized from the same shaped dataset.

Repeated listing cards

The repeat region is the second consumer of listing_results.data. This is the core App Connect pattern in the renewed demo: one shaped collection, multiple synchronized outputs.

Wrap-up

You have now followed the renewed demo’s real architecture: Server Connect loads the catalog, Data Views shape the collections, and the UI binds those shaped results into cards, sliders, filters, and maps.

Next steps

Continue with the broader Data View guidance or return to the App Connect tour index from here.

Dynamic Events

Dynamic Events overview: preview the ( + ) menu, open the Actions Picker for an existing event, and understand common modifiers.

Introduction

Dynamic Events connect user interactions (click, submit, keyup, …) to actions. You configure them visually in Properties.

What you’ll learn

You’ll preview the ( + ) menu (categories → submenus), then inspect an existing Click event and open its Actions Picker.

Add

Use Dynamic Events ( + ) to add event handlers to the selected element.

Pick actions

Use the Actions Picker to build an action list safely.

Control behavior

Use modifiers like prevent/stop/once and key/button modifiers.

Select an element

Add an event

Pick actions + configure modifiers

Open the tour page

This tour opens a small counter page so you can inspect an event/action flow.

Add a Dynamic Event

Dynamic Events are added from Properties via ( + ). Available events depend on the selected element.

Selected element

A real element with no existing Dynamic Events is auto-selected so you can see the full ( + ) menu.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on Dynamic Events menu and see how it fits into this area.

This ( + ) menu lists the available event handlers for the selected element, grouped into categories and, in some cases, submenus.

Inspect an existing Click event

Now the tour selects a button that already has a dmx-on:click event, so you can inspect its Actions Picker without adding anything new.

Actions Picker

Events run an ordered list of actions. The Actions Picker builds and edits that list.

Actions Picker (Click)

The Actions Picker shows what runs on Click so you can inspect and edit the action list. This step matters because Actions Picker (Click) is part of Selection Panels Properties Click, and understanding that context makes the next action easier to repeat in your own project.

Pick actions from the left tree, then configure action inputs on the right.

Selected actions (order matters)

This list is what runs when the event fires. Reorder actions to change behavior.

Close Actions Picker

Close the Actions Picker to return to Properties. This step matters because Close Actions Picker is part of Popup Actionspickup Button Cancel, and understanding that context makes the next action easier to repeat in your own project.

Modifiers (optional)

Modifiers let you control default behavior and propagation without writing manual code.

Review modifiers

Modifiers change behavior (prevent default, stop propagation, capture, once) and can add key/button conditions. The tour opens a dropdown so the options are visible while explaining.

note: Modifiers are a quick way to express common patterns (prevent default, run once, only on Enter, etc.).

Common modifier patterns

Examples: use prevent + stop for links/buttons, once for one-time actions, and key modifiers to run only on Enter (for key events).

Conclusion

Next: learn how events and dynamic attributes work together.

Pick your next tour

Continue with related tours.

Edit form state restoration

Use the Demo Projects HQ task edit form to see how existing record data restores text, select, date, and tag fields before the user starts editing.

Edit forms must restore state before the user edits

The task edit page shows the real difference between create and edit forms. On an edit page, controls should already reflect the stored record so the user is correcting or extending data, not rebuilding it from memory. App Connect bindings make that restoration explicit.

The record loads first.

Bindings restore values into the visible controls.

The user starts from the current state instead of an empty form.

The edit page starts from one loaded record

The task edit form works because sc_task loads the current record first, then the rest of the form binds against that source. Without a stable record source, the edit page would have no reliable state to restore.

Text fields restore the saved record directly

#task_title is the simplest restoration example. The field does not ask the editor to remember the old value or reload it manually. App Connect binds the stored title straight back into the control before editing begins.

Current choices are restored in select controls

#task_assignee, #task_status, and #task_priority are edit-state proof that restoration is not just for text boxes. The visible control has to reflect the saved relationship or status before the user changes it, or the edit form stops being trustworthy.

Dates and tags need restoration just as much

#task_start, #task_due, and #task_tags show the more advanced side of restoration. Complex controls still need a current value before the editor interacts with them, otherwise the page silently turns an edit workflow back into a create-from-scratch workflow.

Conclusion

An edit form is trustworthy only when the visible controls already match the saved record. Once that restoration pattern is clear, field editing, validation, and submit logic all become easier to reason about.

Restore values before the user changes anything.

Use the same record as the source across related controls.

Keep the edit experience stable across text, select, date, and tag fields.

Events & actions

Learn how App Connect turns user interactions into declarative behavior: choose an event, attach one or more actions, apply modifiers, and let bindings react to the updated state.

Events & actions

This tour builds the event-to-action mental model that underpins most App Connect interactions. You will trace how a user event is configured in Properties, how Wappler stores the action list behind that event, and how the rest of the page reacts when the action runs.

Event → action

The goal is to read an event configuration like a simple sentence: when this happens, run these actions, then let bindings and components respond. Once that clicks, click, submit, and keyup handlers all follow the same pattern.

Event

When something happens.

Action

What should run.

Reactivity

Actions update data → UI updates automatically.

Where you configure it

Events, actions, and modifiers are configured in the Properties panel for the selected component.

Working with the Click event and modifiers

The Click event is the most common event. Modifiers control default behavior and add conditions.

Click event actions live on the Click property

The Actions Picker lives on the Click property. Read it as the action list for this selected element: when the click event fires, these configured actions run in order.

Use modifiers

Use prevent/stop/once/capture and key/button modifiers to control behavior without manual code. This step matters because Use modifiers is part of Selection Panels Properties Clickmods, and understanding that context makes the next action easier to repeat in your own project.

Conclusion

Next, go deeper into collections and traversal.

Pick your next tour

Continue learning App Connect.

Use the real files page to see how App Connect turns loaded file rows into summary cards, outbound file links, and project-navigation links.

Introduction

The files page is a good App Connect example because it does more than repeat rows. It turns one loaded files dataset plus one summary dataset into dashboard cards, outbound file links, and internal project navigation that stay readable after every upload.

Start from the real files page and its loaded datasets.

See how summary cards and repeat rows read from those datasets differently.

Follow the two kinds of links the page exposes: file URLs outward and project routes inward.

Frontend: loaded file data becomes a usable library surface

App Connect makes the files page practical because one dataset can feed several UI layers at once. The same loaded file rows support the stats cards, the repeated table, direct file links, and project-navigation links without duplicating fetch logic.

The files page combines upload, summary, and library views

Start on the real files page so the whole surface is visible before narrowing into the cards and table. This page is where recent uploads become a usable library instead of disappearing into backend-only state.

Summary cards reuse loaded file data instead of fetching a separate dashboard just for display

The quick stats cards mix sc_files and sc_summary to give the page an immediate read on document types and total volume. That keeps the page informative before the user scans the row-level library below.

The repeated table turns each file record into one readable library row

#files_list repeats the loaded sc_files rows directly, so every record keeps its filename, project, client, size, and uploaded timestamp together. That is the App Connect handoff from loaded data to a browseable library view.

The file link hands control out to the stored file URL

Inside each repeated row, the filename link binds directly to url and opens in a new tab. That keeps the library practical because a stored file becomes immediately inspectable or downloadable without extra controller logic on the page.

The project link keeps the file row connected to its business context

The project cell binds an internal route to /project/ plus project_id, so the same row can move the user from a file artifact back into the project that owns it. That is a second handoff path coming from the same loaded record.

Conclusion

The files page works as a usable library because App Connect keeps the loaded data reusable. The page can summarize the dataset, repeat it into readable rows, and hand the user either out to the file itself or into the related project without asking for another mental model.

Reuse one loaded dataset across summary and detail UI.

Let repeated rows carry both external file links and internal app navigation.

Treat library pages as active workflow surfaces, not passive reports.

Files upload state and refresh

Use the Demo Projects HQ files page to see how App Connect form state, live data reloads, and repeated file listings stay in sync during uploads.

Introduction

The Demo Projects HQ files page is a practical App Connect upload example because the page does not stop at submitting a form. It tracks request state, shows success feedback, reloads live datasets, and immediately reflects the uploaded files in repeated UI.

Start from the real files page and upload form.

See how App Connect exposes request state and success results.

Follow the page refresh loop that makes new files visible right away.

Page state: loaders, form state, and visible results

The files page keeps App Connect responsibilities explicit. Server Connect components load the existing files and project choices, the upload form exposes request state, and the page binds those outputs back into alerts, buttons, and repeated data.

The files page combines loaders and upload UI in one place

Start on the real files page so the loader components, upload form, and repeated file list stay visible in one context. This page is useful because upload state and visible results live together instead of being split across separate screens.

The upload form exposes request state and success output

#file_upload_form is more than a submit surface. It posts to /api/files/upload, exposes executing and lastError state, and returns save_uploads output that the page can use for success feedback without custom response parsing.

Project selection and Dropzone stay part of the same form contract

#upload_project_id and #files_dropzone belong to the same App Connect form state. The selected project travels with the uploaded files, so the page can treat one submission as both file transfer and project-specific context.

Success actions reload the datasets the page depends on

The form success hook resets the Dropzone and calls sc_files.load() plus sc_summary.load(). That refresh loop is what makes the UI feel immediate: the page asks the same loaders for fresh data instead of guessing what changed.

The table repeats the refreshed files dataset

#files_list repeats over sc_files.data.files, so new rows appear when the loader refreshes after a successful upload. That keeps the visible library tied to one authoritative dataset rather than to ad hoc DOM updates.

Conclusion

The files upload page works well because App Connect keeps each phase visible. The form exposes request state, the success handler refreshes the dependent datasets, and the page simply rebinds to the refreshed outputs.

Let form state drive upload feedback instead of custom response handling.

Reload the page datasets that matter after success.

Bind the UI to refreshed data instead of patching rows manually.

Flows (multi-step client workflows)

Learn when App Connect flows are worth introducing, how they differ from a single event → action handler, and how to think about multi-step client workflows before building them.

Introduction

This introduction sets the decision rule for flows before you start building one. You will compare a simple event handler with a staged workflow, identify the kinds of UI tasks that benefit from multiple ordered steps, and see how flows keep that logic readable as it grows.

Tour goals

By the end of this tour, you should be able to decide whether a feature needs a flow at all, describe the sequence of steps the flow must coordinate, and recognize the parts of the Wappler UI where you inspect and maintain that workflow.

Decision point

Learn when a single event action is enough and when the workflow needs its own staged flow.

Sequence

Break a client workflow into clear ordered steps so side effects stay readable.

Maintenance

See where flows stay easier to reason about as conditions, async work, and branching grow.

Compare a simple event handler with a true multi-step workflow

Identify the steps, decisions, and side effects the client flow must coordinate

Use that mental model to choose the right App Connect tool before implementation

When to use flows

Flows are useful for multi-step UI workflows where you want a clear sequence; simple interactions can stay as a single event → action.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Form data sources on the task form

Use the Demo Projects HQ task form to see how App Connect and Server Connect data sources feed projects, contacts, and tag choices into real form controls.

Real form controls depend on live data sources

The new-task page is not driven by static markup alone. Projects, contacts, and tag suggestions all arrive through data components first, then feed the controls users actually interact with. This tour stays on that page so the data-to-field relationship stays concrete.

Server Connect components load the option data.

App Connect bindings feed that data into form controls.

The field stays readable because source data and displayed choice are kept separate.

The task form pulls several datasets into one page

The task form is useful because it depends on multiple upstream datasets at once. Projects, contacts, and tag suggestions are all loaded before their controls can behave properly, so the page becomes a good map of data-source responsibilities.

Projects feed the project picker

#task_project depends on the projects dataset, not on hard-coded option rows. That is what lets the same field stay useful as projects change over time without rewriting the control itself.

Contacts feed the assignee field

#task_assignee is a separate control, but the same principle applies: the form stays flexible because the contact options come from data that already belongs to the page, not from a duplicated static list inside the markup.

Tag suggestions feed the richer tag field

#task_tags shows that richer widgets still follow the same source-data rule. Tagify only feels guided because the suggestions are loaded first and then mapped into the control, rather than being invented at interaction time.

Conclusion

The task form becomes much easier to reason about when you separate where option data comes from from how the control presents it. That is the bridge from ordinary form markup into practical App Connect form work.

Load option data before expecting controls to use it.

Keep source datasets readable and reusable.

Treat field chrome and backing data as related but different concerns.

Form inputs & bindings

Use common form controls as live App Connect data sources in Wappler, and learn how bindings, events, and type conversion interact while users type, select, and toggle values.

Form inputs & bindings

This tour uses real form controls to explain how App Connect reads and reacts to user input. You will inspect where values come from, how bindings expose those values in Wappler, and where event timing or string conversion changes the result you see.

What you’ll learn

This tour explains how real form controls behave once App Connect is involved: where their values come from, when those values are strings, how grouped inputs expose a shared result, and which bindings you reach for in day-to-day form work.

Bindings

dmx-bind:value and input.value

Types

Inputs are strings; use toNumber() when needed

Groups

Checkbox and radio groups expose one group value

Bind an input to a Variable

Read values from checkboxes/radios/selects

Use toNumber() for numeric logic

Where you configure it

This tour selects a real form field and then highlights its binding and event controls in Properties (so you know exactly where to configure it).

Bind an input to a Variable

A common pattern: store form state in a Variable, then bind an input to it.

Variable (state source)

This Variable holds the value used by the input binding.

Input (value source)

Inputs expose their current value as inputId.value, and can also be bound to App Connect state.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on Value binding (dmx-bind:value) and see how it fits into this area.

Value binding (dmx-bind:value)

This field’s value binding is configured visually in Properties. Use the picker to insert a valid expression.

Changed event action

This event is where you attach actions that should run after the value updates. This step matters because Changed event action is part of Selection Panels Properties Changedvalue, and understanding that context makes the next action easier to repeat in your own project.

Types: inputs are strings

Form inputs are strings by default. Convert to numbers explicitly when doing math or comparisons.

Age input

This number input is still a string value in expressions until you convert it.

Use toNumber() when needed

Convert strings to numbers to avoid surprising results (like ‘2’ + 1 → ‘21’).

important: When you read a value from an input or from Query Manager, treat it as a string unless you convert it.

ageInput.value.toNumber()

query.id.toNumber()

Use numeric comparisons after conversion

Checkboxes: checked vs value

Checkbox inputs expose a boolean checked state. Bind to checked when you want true/false.

Switch checkbox

This switch uses dmx-bind:checked to sync with App Connect state.

Checked binding (dmx-bind:checked)

This binding controls the checkbox checked state using an expression (true/false). This step matters because Checked binding (dmx-bind:checked) is part of Selection Panels Properties Checkedvalue, and understanding that context makes the next action easier to repeat in your own project.

Checked event action

Use the Checked event to run actions when the user toggles the checkbox. This step matters because Checked event action is part of Selection Panels Properties Checked, and understanding that context makes the next action easier to repeat in your own project.

Checkbox Group (multiple selection)

Use a Checkbox Group wrapper to treat a set of checkboxes as one value source.

tip: In Wappler, use the Checkbox Group component so you can bind to one group value and keep the structure clean.

Selects and radio groups

Select and Radio Group controls are common for single-choice input.

Country select (value)

A select control exposes the currently selected value as selectId.value.

Selected value binding (dmx-bind:value)

This binding controls the select’s selected value using an expression. This step matters because Selected value binding (dmx-bind:value) is part of Selection Panels Properties Selectvalue, and understanding that context makes the next action easier to repeat in your own project.

Changed event action (select)

Attach actions here when you need to react to the newly selected value. This step matters because Changed event action (select) is part of Selection Panels Properties Changedvalue, and understanding that context makes the next action easier to repeat in your own project.

Radio Group (single selection)

Use a Radio Group wrapper for a set of radios so you can read one group value.

Preview mode: see values update

Switch to Preview mode and change a few controls. The Live preview card updates immediately via bindings.

Preview mode

Switch the page to Preview mode so you can interact with it like a real app.

Wait for Preview mode

Wait for the page to finish switching modes.

Checkbox interaction

We’ll toggle the Agree switch. Notice how demoForm.agreeSwitch.checked updates in the Live preview.

Country select value

The tour selects another Country value so you can see demoForm.countrySelect.value update in the Live preview.

Checkbox group value

The checkbox group aggregates checked items into one array value (demoForm.interestsGroup.value).

Another checkbox selection

Selecting another interest appends another value to the group array.

Radio interaction

We’ll pick a plan option. demoForm.planGroup.value reflects the selected radio.

Try typing in the name field

Edit the Full name field and watch both fullName.value and demoForm.nameInput.value change in the preview panels.

Return to Edit mode

Switch back to Edit mode to continue inspecting components.

Event timing (change vs changed)

When you run actions based on input changes, prefer App Connect’s changed/updated events when you need the updated value.

Prefer changed/updated for "latest" values

If you attach actions to input events, ensure you’re using the event that runs after the new value is in state.

tip: Common workflow: dmx-on:changed → set value / run validations / trigger data reload.

Use changed/updated when actions depend on the new value

Keep logic in actions, not inline scripts

Use pickers to select actions safely

Where to attach actions

Attach actions on the selected field (or on the form) in Properties. This step highlights the Dynamic Events section, where dmx-on:changed is a common choice for “latest value” workflows.

Wrap-up

Next, validate inputs and submit them to the server.

Next steps

Pick a related tour to continue.

Form Repeat

Learn how Form Repeat structures nested form rows in Wappler so users can add, remove, reorder, and submit repeated data as one coherent request.

Form Repeat

This tour explains both the UI problem and the data model behind Form Repeat. You will look at how repeated rows are defined, which controls manage those rows, and how Wappler turns the repeated inputs into structured data the server can process.

What it solves

By the end, you should recognize when Form Repeat is the right tool: whenever users need to manage a variable number of related entries in one form and you want Wappler to keep the repeated fields, controls, and submitted payload aligned.

Nested data

Submit arrays of fields (items[name][], items[qty][])

UI controls

Add/remove/duplicate/move rows visually

Constraints

Min/max items + optional sorting

Configure items + min/max

Add controls with actions

Submit nested fields in one request

Where you configure it

This tour selects the Form Repeat component in App Structure and then inspects its Items/min/max/sortable properties in Properties.

Core properties

Configure what repeats and how it behaves.

Form Repeat component

This component repeats a block of form fields for each item. This step matters because Form Repeat component is part of the Structure panel, and understanding that context makes the next action easier to repeat in your own project.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on Items (what repeats) and see how it fits into this area.

Items (what repeats)

Items is bound to an array source. Each row gets its own scope (name/qty in this example). This step matters because Items (what repeats) is part of Selection Panels Properties Formrepeatitems, and understanding that context makes the next action easier to repeat in your own project.

Min items

Min prevents removing rows below a required count. Use canAdd/canRemove to keep buttons in sync.

tip: Bind disabled to lineItems.canAdd / lineItems.canRemove so controls stay in sync with min/max.

min keeps at least N rows

Bind disabled to canRemove when at min

Prefer clear UX for required rows

Max items

Max prevents adding too many rows. Pair it with canAdd so the Add button disables at the limit.

max prevents too many rows

Bind disabled to canAdd when at max

Keep constraints visible to users

Sortable + handle

Enable sortable for drag reordering, and set a handle selector so only a handle can drag.

important: Use a handle (like .handle) so inputs remain easy to edit without accidental drags.

sortable enables drag reorder

handle selects the drag grip element

animation controls drag animation duration

Handle selector

Handle is the CSS selector that defines the drag grip (so editing inputs doesn’t start dragging).

tip: In this page, the drag button uses the class .handle, so Handle is set to .handle.

Animation (ms)

Animation controls how long the drag reorder animation runs (in milliseconds).

Keep it short (e.g. 150–250ms)

Use 0 to disable animation

Don’t over-animate data entry UIs

Actions and events

Form Repeat includes actions for adding, removing, moving, duplicating, and resetting rows.

Common actions

Attach these actions to button click events via the Actions Picker.

repeat.add()

repeat.remove($index)

repeat.duplicate($index)

repeat.moveBefore($index) / moveAfter($index)

repeat.reset()

Common events

Listen to lifecycle events like added/removed/moved when you need to trigger follow-up logic.

dmx-on:added

dmx-on:removed

dmx-on:moved (oldIndex/newIndex)

dmx-on:duplicated

dmx-on:updated

Preview mode: try the repeat controls

Switch to Preview mode and use the controls to add/duplicate/remove rows. This shows how repeat actions drive the UI.

Preview mode

Switch the page to Preview mode so you can interact with it like a real app.

Wait for Preview mode

Wait for the page to finish switching modes.

Add item button

We’ll click Add item to append a new row (until max).

Duplicate a row

Duplicate copies the row values into a new item.

Remove a row

Remove deletes a row. When you hit min, the button disables via lineItems.canRemove.

Try editing row fields

Edit the Name/Qty inputs, then duplicate a row to see the values carry over.

Reset back to initial items

Reset restores the original array so you can try again.

Return to Edit mode

Switch back to Edit mode to continue inspecting components.

Wrap-up

Next, connect the repeated fields to a Server Connect form for nested inserts/updates.

Next steps

Pick a related tour to continue.

Form validation (Validator)

Client-side form validation: configure App Connect Validator and integrate with Bootstrap validation feedback and classes.

Introduction

Demo Projects HQ already uses App Connect Validator on real forms, so there is no need to explain validation from an isolated sample. The new-task form combines required text fields, number rules, select validation, and Server Connect feedback in one page. This tour stays on that concrete form so you can see how validation rules, messages, and request-state feedback cooperate in an actual workflow.

Real field rules

Required, minlength, numeric, and date-oriented rules already exist on the live task form.

Real submission flow

The same form also shows how validation fits beside Server Connect success, error, and executing states.

Inspect Validator where a real form already depends on it.

Keep rule attributes and user-facing messages together so the form stays explainable.

Use built-in validation rules before inventing custom client logic.

Treat validation and submit-state feedback as one editing experience, not separate concerns.

Task title is a real validated text field

This title field is a concrete validation example from Demo Projects HQ. It is required, it enforces a minimum length, and it keeps its guidance close to the field instead of hiding the rule somewhere else in the page.

Properties panel is where the validation contract becomes readable

With the title field selected, the Properties panel exposes the validation contract in one place: required state, value limits, and the messages that explain failures back to the user. That is the pattern to preserve as your forms grow.

Required and minlength work together on the title field

The task form does not stop at a bare required flag. Demo Projects HQ also adds a minimum length and a matching message, which means the field can tell the editor both that a title is missing and that a one-character placeholder is not enough. That combination makes validation feel intentional instead of punitive.

Number fields show how Validator scales beyond text inputs

Estimated hours uses numeric validation and a minimum boundary, with messages that explain both invalid numbers and values below zero. This is the same validator workflow, just applied to a different input type. The important point is that the field still declares its rules locally instead of depending on custom click handlers.

Validation matters on data-bound selectors too

Project is not a freeform text box, but it still needs validation. Demo Projects HQ marks the project picker as required and supplies a clear message so the user understands why the task cannot be saved until a project relationship exists. That is a good reminder that Validator belongs on the whole form, not just on simple text fields.

Validation and Server Connect feedback belong to one workflow

The task form also shows success, request-state, and server-error feedback through task_form.data, task_form.state, and task_form.lastError. Client-side validation should stop obviously bad submissions early, but the complete user experience still includes request progress and server responses after the form is allowed to submit.

important: Do not treat Validator as a replacement for server-side checks. In Demo Projects HQ it works alongside the real submit action and its response state.

Next steps

The Demo Projects HQ task form shows the validator pattern clearly: keep each field’s rules close to the field, pair them with plain-language messages, and let the form’s real submit state complete the feedback loop. That gives you a reusable baseline for every other App Connect form in the project.

Formatters (transform data for display)

Use App Connect formatters to transform values (date, currency, text, collections) using Wappler’s expression picker.

Formatters

Formatters transform values for display and simple data manipulation, without changing the source data — applied visually via the expression picker.

What a formatter is

A formatter is a method-like helper you chain in an App Connect expression (for example: text case, date formatting, currency). In Wappler you typically pick them from the expression picker.

Display-friendly

Format dates, currency, percentages, truncation.

Declarative

Keep formatting declarative in expressions.

Composable

Chain multiple formatters to get the final output.

Keep source data unchanged

Transform at the point of display

Use the picker to discover available formatters

Component folder requirement

Using formatters requires the formatter extension/component folder to be present (dmxFormatter). If you don’t see formatters in the picker, check your installed frameworks/extensions.

tip: In practice, Wappler project templates typically include the needed App Connect packages. Missing formatters often means a missing/disabled extension.

Verify dmxFormatter is installed

Check framework/extension setup

Use the picker to browse available formatters

Using the picker

In Wappler, formatters are easiest to apply via the expression picker in any bindable field.

Any bindable field can use formatters

Look for fields with an expression/binding picker (Value fields, text bindings, filters, class bindings, etc.). That’s where you can apply formatters.

Common formatter categories

Use formatters to transform strings, numbers, dates, and collections right where you display them.

Strings: lowercase/uppercase/titlecase/trunc

Numbers: formatCurrency/formatNumber/toFixed

Dates: toDate/formatDate/addDays

Collections: count/sum/avg/where/hasItems

Best practices

Avoid common mistakes and keep expressions readable.

Use the App Connect formatter names

Use the formatter names shown in the picker (lowercase/uppercase/titlecase, etc.) so you get valid results at runtime.

important: If something doesn’t appear in the picker, it’s usually not a valid formatter for that value. Prefer picking over typing.

Pick formatter names from the UI

Avoid typos in hand-written chains

Use type conversion when needed

Convert types before formatting

If a value is a string but you need numeric/date formatting, convert first (toNumber/toDate), then format.

string → toNumber → currency/number formatting

string → toDate → formatDate/addDays

check isDefined before converting when data is optional

Use filtering where it fits

Formatters are great for display and small transforms, but avoid using collection filtering formatters as a replacement for real filtering and paging on large datasets.

warning: If you notice slow UI updates, move filtering out of the browser and into Server Connect or Data View.

Small datasets: simple collection formatters are fine

Bigger datasets: use Data View for filter/sort/page

Very large datasets: filter/page in Server Connect and return only what you need

Conclusion

Formatters help you keep data clean and UI readable — applied right where you display values.

Pick your next tour

Continue with validations or filtering.

Local Manager (persistent settings)

Learn when Local Manager is the right persistence layer for Wappler UI state, and how to store settings that should survive reloads without going to the server.

Local Manager

This tour positions Local Manager as client-side persistence for everyday UX settings. You will look at what kinds of data belong here, how Wappler reads and writes those values in bindings and actions, and where the limits and security boundaries are.

When local storage is the right choice

You are not just learning that local storage persists data. You are learning the decision rule: use it for convenience settings and cached UI preferences that should remain on the same browser, but never for secrets or security-sensitive state.

Persistent settings

Theme, layout density, last selected view.

No server dependency

Stays in the browser until cleared.

Bigger than cookies

Typically larger capacity than cookies.

Survives browser restart

Good for preferences

Avoid sensitive data

Objects are supported

Local Manager can store complex objects; they’re serialized/deserialized automatically.

important: Local storage is readable by client-side code. Don’t store secrets or tokens here.

Prefer non-sensitive data

Keep payloads reasonable

Provide a “reset settings” action

Core workflow

Bind UI to local values, and update them on events.

Write local state

Use local.set(key, value) to persist a setting, and local.remove/removeAll to reset.

set(key, value)

Stores a persistent value.

remove(key)

Removes one setting.

removeAll()

Clears all stored settings.

Save user preference

Apply it via bindings

Offer reset button

Read local state in bindings

Use local.key in expressions to set classes, default values, and visibility.

Pattern: app settings form

Bind form controls to local values and save changes with a single submit action.

Controls read local.*

Submit writes local.set(...)

UI updates instantly

Wrap-up

Next, decide whether your state belongs in local/session/cookie or in the URL.

Next steps

Pick a related tour to continue.

Organization best practices (data-first)

Keep App Connect pages readable and fast: organize non-visual data components (Variables, Data Stores, Server Connect) at the top, named and grouped before UI usage.

Introduction

This tour uses a deliberately structured page to show why App Connect projects stay easier to maintain when data comes first. You will compare the visual layout with the non-visual components that feed it, then use that example to build a stronger mental model for grouping, naming, and placing state and data sources in Structure.

Overview

Make complex pages easier to read and faster to reason about by organizing non-visual data components (state, collections, API) at the top — before any UI uses them.

Readability

Find state, collections, and API calls instantly.

Maintainability

Clear naming + grouping prevents "where is this coming from?" debugging.

Performance

Avoid accidental duplicate loads and heavy repeated work.

Group data components at the top of Structure

Name components by purpose (not "store1")

Declare data before bindings/actions use it

Keep UI below: it should only consume data

What you’ll see on the page

This example page is intentionally organized with non-visual components first, then UI sections below that only consume those data sources.

A dedicated top section for data components

State grouped together (Variables/Toggles)

Collections grouped together (Data Store + Data View)

API grouped together (Server Connect)

Data-first structure

Non-visual data components (state, collections, API) belong at the top of the page so everything below can reference them clearly.

Data section

This top section contains the page’s non-visual data components (state, collections, API). We’ll select it so you can see how it’s organized.

Why keep data at the top

Keeping non-visual components at the top makes pages easier to read: you can scan state, collections, and API endpoints before looking at UI bindings.

Put Variables/Toggles/Arrays at the top (state)

Put Data Stores + Data Views near each other (collections)

Put Server Connect components at the top (API)

Keep UI sections below: forms/cards/tables consume data

Performance: when to localize data

Keeping data components at the top is a great default — but if a dataset is used only inside a view that is loaded conditionally, declare that data inside the conditional region so it isn’t always processed.

The same idea applies to repeaters: pick the repeater style that avoids extra wrappers, and only set the key field when you truly need it (animations / stable DOM row identity), because it slows down the repeater.

Important exception: inside Repeaters and Data Detail areas, prefer dmx-show/dmx-hide for empty/selected UI so the DOM stays stable (and inputs don’t reset).

important: Best performance: isolate optional/heavy sections with a Conditional Region (dmx-if) so their child components don’t render until the condition is met. Exception: inside Repeaters and Data Detail, prefer dmx-show/dmx-hide to keep the DOM stable.

Global/shared data: keep at the top (state, shared collections, API endpoints)

Conditional-only data/components: declare inside that Conditional Region

Prefer Conditional Region (dmx-if) for heavy optional UI so the region isn’t rendered until needed

Inside Repeaters and Data Detail: prefer dmx-show/dmx-hide for empty/selected UI to keep DOM stable

Show/Hide dynamic attributes (dmx-show / dmx-hide) only toggle CSS visibility; they don’t prevent processing

Performance: filter where it belongs

When a page grows, performance problems often come from loading or processing too much data on the client. Keep UI expressions light, and push heavy filtering/paging to the right layer.

important: Treat client-side filtering formatters as a convenience, not a replacement for Data View or Server Connect filtering on large datasets.

Small UI transforms: formatters are fine

Interactive filtering/sorting/paging: use a Data View

Very large datasets: filter/page in Server Connect and return only what you need

Naming convention

Use IDs that read like purpose: what it stores/loads (usersStore, usersView, apiUsers) rather than generic names (store1, data_view1).

tip: Good IDs become self-documenting in expressions: usersStore.items, usersView.data, apiUsers.data, currentUserName.value.

Prefer purpose-based IDs (usersStore/usersView/apiUsers)

Avoid generic IDs (store1/data_view1)

Keep a consistent naming prefix per feature area

Let the ID read well inside expressions (usersStore.items)

Walkthrough: state → collections → API

Select a few data components and see how their IDs are used by bindings below.

State Variable

This Variable holds a piece of state used in bindings (for example: currentUserName.value). We’ll select it to review its ID and value.

Orient yourself in Properties panel

Start with the wider context in the Properties panel so the next control makes sense in the full workflow. In the next step, you will focus on ID drives expressions and see how it fits into this area.

ID drives expressions

When IDs are clear, bindings read like plain English. This is why naming + organization matter.

Data Store

A Data Store holds a collection of records. We’ll select it and keep related Data Views nearby so it’s always clear where UI lists come from.

tip: Put collections on top (Data Store, Query, API results) and keep UI repeats/tables below them.

Data View

A Data View is a read-only lens over a collection (filters, sorting, paging). We’ll select it to see how it stays close to its data source.

Server Connect component

This Server Connect component loads data from the server. We’ll select it so it’s easy to find, review, and avoid duplicating API calls in UI sections.

important: Best practice: don’t place Server Connect components inside repeats/cards. Keep them centralized and bind UI to their results.

Use data in the UI

With data components declared first, UI bindings stay simple and easy to understand.

Bound UI element

This badge’s text comes from a binding (for example: currentUserName.value). We’ll select it and then inspect the binding in Properties.

Inspect the binding in Properties

This is where you see (and edit) the expression used for the selected element’s text. This step matters because Inspect the binding in Properties is part of Selection Panels Properties Innertextvalue, and understanding that context makes the next action easier to repeat in your own project.

tip: When data components are clearly named, bindings stay short and readable.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Performance: conditional rendering (dmx-if)

Improve App Connect performance by using conditional regions (dmx-if) and placing conditional-only data/components inside them so they don’t render or process until needed.

Introduction

This tour uses a focused example page to explain a practical App Connect performance decision: when to avoid rendering work entirely instead of merely hiding UI. You will compare conditional regions with show/hide behavior, then connect that choice to component scope, repeated DOM cost, and page readability.

Performance: render only when needed

Improve performance by rendering less: use conditional regions (dmx-if) for UI that depends on a condition, and place conditional-only data/components inside that region so they don’t exist until the condition becomes true.

Conditional rendering

Use dmx-if so UI and components don’t render until needed.

Avoid hidden work

dmx-show/hide only toggles CSS visibility; components still exist and can be processed.

Scoped data

Keep global data at the top, but localize data used only inside conditional views.

Prefer dmx-if over dmx-show/hide for conditional UI

Declare conditional-only data/components inside the dmx-if region

Keep shared/global data at the top for readability

Use conditional regions to isolate heavy sections until needed

Repeaters: performance tips

Repeaters can generate a lot of DOM. Prefer the simplest repeater that matches your layout, and only set Unique Key when you truly need it (it slows down the repeater).

Repeat (dynamic attribute) repeats the element itself (dmx-repeat:*)

Repeat Children (component) repeats children only (is="dmx-repeat")

Only set Unique Key when needed (animations / stable DOM identity)

Conditional rendering vs show/hide

Understand why dmx-if is recommended for performance and how it changes what gets rendered.

Conditional Region vs Show/Hide

Use a Conditional Region (dmx-if) when a part of the page depends on a condition or isn’t needed right away.

important: Best performance: use Conditional Region (dmx-if) for conditional UI, not Show/Hide dynamic attributes.

Conditional Region (dmx-if): when false, the region is not rendered (no DOM nodes, no child components)

Show/Hide dynamic attributes (dmx-show / dmx-hide): toggle CSS visibility only; the region is still rendered

Performance tip: use a Conditional Region for heavy/optional sections so they aren’t processed until needed

Conditional Region (dmx-if)

This section uses a Conditional Region (dmx-if), so it only exists when the condition is true.

Place conditional-only data inside

If a Data View, Data Store, or Server Connect component is used only inside a section that’s shown conditionally, declare it inside that Conditional Region (dmx-if) so it isn’t processed until needed.

tip: When the condition is false, the Conditional Region and its child components don’t exist at all.

Global/shared data: keep at the top for readability and reuse

Conditional-only data/components: declare inside the dmx-if region

This prevents “always-on” processing for sections users may never open

Show dynamic attribute (dmx-show)

This section uses the Show dynamic attribute (dmx-show), so it stays in the page structure and its child components exist even when hidden.

warning: Show/Hide dynamic attributes are visibility toggles (CSS). They do not prevent rendering/processing of the region’s components.

Local data inside Conditional Region

This data component lives inside the Conditional Region. Keeping conditional-only data/components inside a Conditional Region (dmx-if) avoids always-on work.

tip: Rule of thumb: global for shared page-wide state; local for conditional-only sections.

Shared global data

Shared state and data that multiple regions use can stay at the top for readability and reuse.

Global data: referenced by multiple UI regions

Local (conditional) data: referenced by one conditional region only

Use dmx-if to isolate heavy sections until needed

Repeaters: performance and key field

Repeaters can generate lots of DOM. Learn when to use each repeater style, and when to avoid the key field for better performance.

Repeaters: Repeat vs Repeat Children

Repeaters can create many DOM nodes. Choose the simplest repeater that matches your layout needs.

Repeat (dynamic attribute): repeats the element itself (and its children) (dmx-repeat:*)

Repeat Children (component): repeats children only (container stays single) (is="dmx-repeat")

Fewer DOM nodes usually means less work when updating

Unique Key: only when you need stable row identity (animations / DOM identification) — don’t set it by default (it slows down the repeater)

Repeat (dynamic attribute)

This example uses Repeat (dynamic attribute). It repeats the element itself. Great for simple repeated elements, but can lead to extra wrapper DOM if you repeat large containers. (dmx-repeat:*)

Repeat Children (component)

This example uses Repeat Children (component). It repeats only the children, so your layout container stays single and clean when building grids/cards. (is=“dmx-repeat”)

Unique Key: only when needed

This Repeat Children repeater sets a Unique Key. Only do this when you need stable row identity (animations, or DOM identification).

warning: Choose the unique key field to identify the repeater’s record. Only needed when you want to use animations or need to identify repeater’s rows in DOM. Do not use if not needed as it will slow down the repeater.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

App Connect Quick Overview

A hands-on intro to App Connect in Wappler: review key components, configure Properties, and attach an event action.

Getting oriented

App Connect makes pages reactive by connecting UI to data and events. You build it visually with components + Properties.

How App Connect works (in Wappler)

App Connect is a reactive layer: components hold data, UI reads that data, and events trigger actions that update data. When data changes, the UI updates automatically.

important: Use Wappler’s Data Bindings Picker and Actions Picker to select data and actions from a tree. This keeps your bindings consistent with what’s in scope.

State

Use Data components (Variable, Array, Toggle) and collections (Data Store) to hold state.

Data Bindings Picker

Browse what’s in scope and insert valid expressions into fields without typing everything.

Visual Expression Builder

Build filter expressions with operators, functions, and in-scope data sources.

Actions Picker

Choose actions (like Set Value) to run when events happen (like a button click).

Review components

Configure Properties

Wire an event → action

Prerequisites

This tour opens a sample App Connect page in Design View. Keep Page Panels (Structure) and Selection Panels (Properties) visible.

Bindings → formatter → repeater → filter expressions → show/hide

Start with a simple text binding and see how currency formatting works. Next, inspect the repeater’s repeat expression, then open the Visual Expression Builder used by the Data View filter. Finally, review a Show/Hide binding.

Simple binding with formatting (auto-selected)

This value uses a binding expression that formats as currency: minPrice.value.formatCurrency('$').

Orient yourself in Properties panel

Text binding expression

This field contains the expression for the selected element. This step matters because Text binding expression is part of Selection Panels Properties Innertextvalue, and understanding that context makes the next action easier to repeat in your own project.

Opening Data Bindings Picker

We’ll open the Data Bindings Picker so you can browse what’s in scope and insert valid expressions without typing everything.

Browse what’s in scope for this field. Since the current expression uses minPrice.value, you should see minPrice (Variable) and its value here.

Find `minPrice.value` (and data in scope)

In the tree, expand minPrice and select its value. That’s the value being formatted as currency in the field.

note: Scope matters: the picker only shows data that’s valid for the current selection.

Active expression tag

The formatter button applies to the active tag. We’ll focus the expression tag so formatting targets the right expression.

Opening the Data Formatter (currency)

We’ll open the Data Formatter so you can inspect or adjust the currency formatting chain.

The Data Formatter lets you build a formatter chain (pipeline) visually and insert it back into the field.

Formatter chain tree

This tree represents your formatter chain. Select a formatter to edit its settings in Properties.

Formatter settings (Properties)

Configure currency symbol, locale, precision, etc. depending on the formatter.

Close Data Formatter

Press Next to close the Data Formatter (Cancel) and return to the Data Bindings Picker.

Close Data Bindings Picker

Now select the repeater (auto-selected)

The repeater displays the Data View results as cards.

Repeat expression

This property points to the collection being repeated (Data View results). This step matters because Repeat expression is part of Selection Panels Properties Control Repeatexpression, and understanding that context makes the next action easier to repeat in your own project.

tip: Use the Data Bindings Picker here to explore the full path (for example: data_view1.data).

Opening Data Bindings Picker (repeat)

We’ll open the Data Bindings Picker so you can inspect the repeat expression in context. This step matters because Opening Data Bindings Picker (repeat) is part of Selection Panels Properties Control Repeatexpression, and understanding that context makes the next action easier to repeat in your own project.

Repeat expression in the picker

This picker is scoped to the repeater. You’ll see item-level fields like title, beds, and price here too.

Close Data Bindings Picker

Close the Data Bindings Picker to continue. This step matters because Close Data Bindings Picker is part of Popup Databindingspickup Button Cancel, and understanding that context makes the next action easier to repeat in your own project.

Data View (Structure)

The Data View defines which records appear. We’ll select data_view1 so you can inspect its filter expression.

Opening filter in Expression Builder

The filter is a rule-based expression. We’ll open it in the Visual Expression Builder so you can inspect the logic.

tip: Use the Visual Expression Builder for logical expressions (filter rules, AND/OR groups). Use the Data Formatter for formatting pipelines.

The Visual Expression Builder helps you build valid expressions with operators, functions, and data sources in scope.

Query builder

Each row is Field + Operator + Value. This is how you define filter rules without typing the full expression.

AND / OR groups

Groups let you combine multiple rules with AND/OR for more advanced filtering.

Expression preview

This shows the final expression that goes back into the filter field when you apply/close the popup.

Close Visual Expression Builder

Review the full Visual Expression Builder one last time. Press Next to close it and return to the Data View properties.

Simple binding: Show (auto-selected)

This panel uses a simple binding to show/hide itself: dmx-show="showDetails.checked".

Show binding (When)

This is the expression behind dmx-show (Show → When). It uses the same Data Bindings Picker and scope rules as your other bindings.

tip: For complex conditions, open the picker and build the expression visually.

Preview the filters in action

Switch to Preview mode and interact with the controls to see bindings update instantly.

Switch to Preview mode

Preview mode makes the page interactive so you can use the controls as a user would.

Wait for Preview mode

Wait for the page to finish switching modes.

Beds filter

We’ll open the Beds dropdown so you can change the minimum beds filter.

Minimum beds value

This dropdown value updates the filter. We’ll pick a higher minimum beds value to narrow the list.

Action button

This button runs an action that updates greeting state. We’ll click it to demonstrate state-driven UI updates.

See the results update

The listing cards and summary badges update immediately when state changes.

Return to Edit mode

Switch back to Edit mode to continue inspecting components.

Wire an event → action

Events are where interactivity starts. You pick an event (click/submit/keyup/…) and assign an action.

Action button

This button is where we’ll attach a Click event. We’ll select actionButton so you can inspect its event and action settings.

Add a Click event

In Properties → Events, enable Click and choose an action. Actions are picked visually (you don’t type raw code for common tasks).

tip: Look for an Action picker (it will help you choose a component action like “Set Value”, “Insert Record”, etc.).

Use event modifiers

Modifiers change behavior (prevent default, stop propagation, capture, once) and can add key/button conditions.

Conclusion

You’ve seen the core workflow: inspect components, configure Properties, and wire an event to an action.

Pick your next tour

Continue with deeper tours on expressions, collections, and filtering.

Reactive basics (data → UI)

A beginner-friendly mental model for App Connect: how data, bindings, events, actions, and Dynamic Attributes combine into reactive UI updates.

Reactive basics

Build an accurate mental model for App Connect: data drives UI, and events run actions that update data. Wappler’s pickers help you wire this visually.

The reactive loop (mental model)

Think of App Connect reactivity like a constellation:

App Connect reactivity as a constellation

Your job is to connect UI properties to data. When data changes, the connected parts update automatically — no manual UI refresh steps.

tip: If the UI looks wrong, check the selected component (scope) and the binding expression.

State holds values (Variable / Store / API)

Bindings read state and render UI

Events trigger actions that update state

Where data can come from (DB / JSON / API)

App Connect doesn’t care where the data came from — once it’s in state, bindings can use it.

The usual Wappler workflow is: Server Connect action loads/writes the database, then bindings display the result.

Most common: database via a Server Connect action (query/insert/update)

Also common: load JSON (file or generated) into state

Or fetch from an external API — then bind the values to UI

Hierarchy + loading (visual model)

This view avoids “expression syntax” and focuses on the visual principles:

Selection defines scope → loading fills data → bindings keep UI + state in sync.

Select something → the Data Picker shows that scope

Loading happens first → data isn’t ready yet

Data arrives (products.data from DB) → values become pickable

Bindings keep UI + state in sync (toggle updates styles)

Same idea, classic view

If you prefer a “loop” mental model, this is the same concept in a simpler sketch:

The key takeaway stays the same: change data → App Connect re-evaluates bindings → the UI stays in sync.

App Structure sets the scope

Use App Structure to select what you’re working on. The selection determines what data and actions are “in scope” for pickers.

Properties is where you wire reactivity

Most reactive setup happens in Properties: bindings, expressions, events, and actions. Look for picker buttons to select data and actions visually.

Data → UI (reactive bindings)

Bindings connect UI properties to data. When the data changes, App Connect re-evaluates expressions and updates the UI.

Bindings are “live” connections

A binding connects a property to an expression (often a data value). When any input changes, App Connect re-evaluates and updates the UI automatically.

note: You usually don’t need “refresh UI” actions. Updating data is enough.

Use the Data Picker to build expressions

When a field supports bindings, click its picker button and choose data from the tree. This keeps you in the correct scope and avoids typos.

tip: If you can’t find a value in the picker, change your selection in App Structure first (scope).

Scope changes what you can pick

The Data Picker is context-aware. Selecting a different component or changing where you are in the hierarchy changes which data and methods are available.

Events → actions → data

User interactions trigger event handlers. Those handlers run actions that update your state (variables/stores) and refresh the UI.

From event to UI update

Interactive pages follow a simple loop:

Most of the time, your job is just: wire the event and pick the action. The UI updates when the data changes.

Pick an event (click/submit/...)

Pick an action (setValue/load/...)

Bindings re-evaluate → UI updates

Common: form → action → database

This is the most common production pattern in Wappler apps:

Form submit to Server Connect action to database

The form doesn’t talk to the database directly — it calls a Server Connect action, which validates input and writes/reads the database.

User fills inputs (local state updates live)

Submit → Server Connect action receives POST data

Action validates + runs DB query/insert/update

Response updates state → UI shows success/errors

Events belong to components

Events are attached to the selected component (button, form, input, etc.). Select the element first, then configure its events in Properties.

Actions Picker and action inputs

The Actions Picker lets you choose what should happen (setValue, toggle, load, insert, update…) and then wire its inputs from the Data Picker.

tip: A good workflow: pick an action first, then wire its inputs from the Data Picker.

Dynamic Attributes ( + )

Some reactive behavior is added as attributes and events via the ( + ) button, not as a pre-defined property field.

Add Dynamic Attributes with ( + )

Some bindings are added as attributes (like show/hide, class, repeat, on click, …). In the Dynamic Attributes section, use the ( + ) button to add them to the selected element.

tip: If you don’t see the Dynamic Attributes section, try selecting a different element (or insert a component that supports those attributes).

Two ways to add reactivity

Binding fields

Some components expose a property field (with a picker icon) that supports expressions.

Dynamic Attributes

Others are added via ( + ): show/hide, class, repeat, on click, and more.

Same model

Both create reactive expressions: when inputs change, the result updates.

If you don’t see a field, look for ( + )

If you don’t see a value, change scope

Let data changes drive UI updates

Why the ( + ) list changes

The Dynamic Attributes list is context-aware: it changes based on the selected element and the installed component rules. If you don’t see an attribute, try selecting a different element or inserting the related component first.

Conclusion

Recap the mental model and pick a next tour.

What to remember

If you keep this loop in mind, App Connect becomes predictable and easy to debug.

Data

State lives in Data components and stores.

Bindings

UI reads data through expressions in Properties.

Events

Events run actions that update data.

Select the right component (scope)

Use pickers to build expressions/actions

Update data → UI updates automatically

Next steps

Choose a focused tour to practice the loop (data → UI) and the pickers.

Hands-on starter

Build something small end-to-end.

Deeper concepts

Learn scoping, expressions, and common patterns.

Interaction

Wire real events and actions.

Quick Overview: insert a Variable + wire an event

Core concepts: expressions + pickers + scope

Events & actions: practical interaction patterns

Routing (views, routes, internal links)

Understand Wappler’s modern hybrid routing: routes, layouts, content pages, and route-aware links.

Modern Wappler routing uses routes, layouts, and content pages

Use this bridge to understand where App Connect fits into modern Wappler routing. The recommended workflow is not inline dmx-route components. Instead, Routing Manager stores the generated route definitions, Pages Manager shows the routed layout and content files, and the layout renders the selected content page through dmx-view as partial content.

App Connect still matters in this flow, but in a different role: it powers the interactive page once the route has already selected the correct layout and content page. Internal links and route-aware components should align with the generated route map rather than reintroducing deprecated inline routing patterns.

Start with the real Routing Manager map

Start with the live Routing Manager map in Demo Projects HQ. This is the source of truth for route-aware App Connect work, because links and routed content should follow the real generated route tree instead of reviving old inline dmx-route patterns.

Pages Manager overview

Keep the full Pages Manager surface in view before focusing on a specific node. This is the second half of the routing picture: the generated route map points to real layout and content files that live here.

Pages Manager shows the routed files

After the route map is clear, switch to the real Pages Manager structure. In Demo Projects HQ, that is where the actual layout and content files behind those routes become visible and selectable.

Server Connect components (data + forms)

Load data and submit forms via Server Connect components, using built-in state (executing/lastError/data).

Introduction

This tour introduces the App Connect components that talk to your server actions. You will see how Wappler models requests, responses, execution state, and errors in the page, and how those component outputs become the inputs for bindings, loading indicators, and follow-up actions.

Tour goals

By the end, you should understand the whole client-to-server loop in Wappler: which component sends the request, where request state is exposed during execution, how returned data becomes available to the page, and where error handling fits into the same declarative workflow.

Request lifecycle

Follow a request from trigger to executing state, response data, and completion.

Bound server state

Use executing, data, and lastError as normal App Connect values in the UI.

Action chaining

See how request components fit into larger event and action sequences on the page.

Inspect the components that load data and submit forms

Understand how request state is exposed for loading and error UI

Reuse returned server data in bindings and follow-up actions

Where you configure it

Use App Structure to select your API Form / API Action components and Properties to bind inputs, outputs, and actions.

Wrap-up

Review what you did and choose a next tour.

Next steps

Pick a related tour to continue.

Bind API Form inputs

Handle executing/data/lastError

Chain actions after requests

Session Manager (per-tab state)

Store temporary workflow state for the current tab using Session Manager; cleared when the tab closes.

Session Manager

Session Manager stores per-tab state for the lifetime of the tab/session. It’s great for wizards and temporary workflow data.

When session storage is the right choice

This tour teaches the decision rule for session storage, not just the API. Use it when workflow state should survive refreshes in the current tab but disappear when that tab’s session ends, which makes it a strong fit for wizards, short-lived progress, and temporary UI context that should not bleed into other tabs.

Wizards

Keep step data until completion.

Per-tab safety

Each tab has its own session storage.

Temporary state

Clears when the tab closes.

Survives reloads

Clears when tab closes

Great for multi-step forms

Objects are supported

Session Manager can store complex objects; they are serialized/deserialized automatically.

tip: Even with objects, keep stored values small and focused.

set(key, value) supports objects

Read with session.key

Clear with remove/removeAll

Core workflow

Bind UI to session values, and update them on events.

Write session state

Use session.set(key, value) in submit/click handlers to store the user’s progress or inputs.

set(key, value)

Stores a value for this tab session.

remove(key)

Removes one key.

removeAll()

Clears session state for the page.

Save intermediate form data

Store selected step/index

Clear on completion

Read session state in bindings

Use session.key in expressions to prefill fields, show status text, or conditionally render UI.

Pattern: multi-step form

Store each step’s data in session storage so refreshes don’t lose progress. Clear on final submit.

Step 1 writes session

Step 2 reads session

Final step clears session

Wrap-up

Next, pick the right persistence level for your app.

Next steps

Pick a related tour to continue.

A practical guide to App Connect storage strategy in Wappler, comparing URL state, cookies, session storage, and local storage through real UI scenarios.

State management in App Connect

This tour gives you a practical storage decision framework instead of four disconnected components. You will compare URL-based state with browser storage options, understand what each one is best at, and connect that choice back to the App Connect actions you actually configure in Wappler.

What you’ll learn

Instead of memorizing four components separately, you will learn the decision logic behind them: which storage belongs to shareable links, which one survives restarts, which one stays tab-scoped, and how each option feeds bindings and actions on the page.

Decide quickly

URL vs cookie vs session vs local.

Use the right actions

set/remove/removeAll (and related).

Connect to UI

Bind controls and render based on state.

Shareable state (URL)

Persistent state (cookie/local)

Temporary state (session)

Where you’ll work in Wappler

These components are configured like any other App Connect component: select in App Structure, set properties, then call actions from events.

Pick the right storage

Use this mental model to avoid accidental UX bugs (state that resets when it shouldn’t, or sticks when it shouldn’t).

URL state: Query Manager

Best when state should be shareable and bookmarkable (filters/search/sort/page/selection).

Shareable

Bookmarkable URL reflects current view.

Great for lists

Search, filters, paging, and sorting.

Type conversion

Remember query values are strings.

Search term in URL

Filter choices in URL

Page number in URL

Best for lightweight preferences and consent flags that should persist across sessions.

Preferences

Theme/language/dismissed banners.

Expires support

Set long-lived cookies when needed.

Small payloads

Keep values small and simple.

Persist across restarts

Optionally set expiration

Avoid sensitive data

Temporary state: Session Manager

Best for per-tab workflows (wizards, temporary drafts) that should survive refresh but clear when the tab closes.

Per-tab

Doesn’t leak across tabs.

Great for wizards

Store step data until submit.

Objects supported

Stores objects via serialization.

Survives refresh

Clears on tab close

Good for multi-step flows

Persistent settings: Local Manager

Best for non-sensitive settings that should “stick” without cookie overhead.

Persistent

Survives browser restarts until cleared.

Objects supported

Stores objects via serialization.

Non-sensitive only

Readable by client-side code.

Great for UI settings

Provide a reset action

Don’t store secrets

Wrap-up

Now pick a deep dive for the storage type you need.

Next steps

Choose a focused tour to continue.

App Connect

Your guided index of App Connect tours: reactive model, data components, bindings, events/actions, and common workflows — explained visually in Wappler’s panels and pickers.

App Connect

Choose an App Connect tour to start. These tours focus on the visual workflow in Wappler: inserting components, configuring Properties, and wiring events (no manual markup required for most tasks).

Forms

Bind form inputs, configure validation, and build repeatable sections using concrete Demo Projects HQ pages where possible.

Forms

Choose a Forms tour to start. The strongest examples here now use real Demo Projects HQ pages, especially the task add/edit forms, so you can see bindings and validation where an actual project already depends on them.

Demo walkthrough: Real Estate listings page

Focused walkthrough of the renewed Real Estate listings page: Server Connect source, Data View filters, synchronized map, charts, and repeated listing cards.

Listings page mental model

The listings page is the clearest App Connect page in the renewed demo. A Server Connect action loads the catalog, a Data View reshapes it, and several outputs stay synchronized from that one shaped collection.

Server data first

`sc_listings` loads the catalog from the server.

One shaping layer

`listing_results` applies filter and sort logic in the browser.

Shared outputs

Cards, charts, and the map all reflect the same active result set.

Server Connect loads the raw list.

Data View filters and sorts it.

Map and card grid both consume the shaped result.

Listings page opens

The listings walkthrough starts on views/listings.ejs, where the renewed demo shows the full filter pipeline on one page.

Listings editor is ready

The listings page is now active in Design View, so the Structure and Properties panels can follow the live page context.

Listings API source

sc_listings calls /api/listings/list and exposes the raw collection for the page. Everything else on this screen builds on that server response.

Listings Data View

listing_results is the shaping layer. It reads the API result, reacts to the input controls, and owns the current filtered and sorted result set.

Filter controls surface

This filter bar is where App Connect becomes practical for users: the controls are ordinary inputs, but their values feed the Data View expression directly.

Market filter control

inp_market is one of the controls inside the Data View filter. It narrows the result set without another request because the filtered collection already lives on the page.

Sort direction control

inp_sort_dir shows that the Data View also owns sorting. The page does not need separate card and map logic for sort order because both outputs read the same shaped collection.

Insights and charts

The listings page mixes shaped result outputs with supporting value components and charts, which makes it a strong example of App Connect feeding multiple visual layers at once.

Map bound to the filtered result

listing_map reads listing_results.data directly, so map markers stay synchronized with the same filtered dataset that drives the visible cards.

Repeated listing cards

repeat_listings is the second consumer of the shaped collection. This is the page’s core lesson: one Data View can drive multiple outputs cleanly.

Wrap-up

The listings page turns the renewed demo into a reusable pattern: load once from Server Connect, shape once through Data View, then let several UI outputs consume the same result.

Next steps

Continue into the detail page, the inquiry form, or the broader App Connect tours from here.

Demo walkthrough: Real Estate listing detail page

Focused walkthrough of the renewed listing detail page: route-driven Server Connect loading, gallery and lightbox, related repeats, map, and inquiry call-to-action bindings.

Listing detail page mental model

The listing detail page shows how the renewed demo handles one routed record. A route parameter loads the listing, then App Connect binds that detailed record into galleries, repeated sections, maps, and call-to-action links.

Route-driven load

`sc_listing` reads the page query id and loads one property record.

Rich detail UI

Swiper, lightbox, repeats, and maps all bind to the same loaded record.

Action handoff

The page links cleanly into the inquiry flow without duplicating data.

Load one record from the route.

Bind the detail record into several UI surfaces.

Pass the current listing into the inquiry workflow.

Listing detail page opens

The walkthrough starts on views/listing.ejs, where the renewed demo turns one routed listing record into a complete detail page.

Listing detail editor is ready

The detail page is now active in Design View, so the Structure and Properties panels can follow the live page context.

Route-driven Server Connect

sc_listing calls /api/listings/get and binds query.id into the request, which is how the detail page resolves one record from the routed URL.

property_lightbox is a good example of page-level App Connect infrastructure: several gallery links can reuse it without duplicating popup logic.

Listing gallery swiper

The swiper uses the loaded record’s listing_images collection, so one API record can immediately power a richer presentation component.

Room-by-room repeat

listing_rooms shows a common detail-page pattern: subquery data from the main record becomes a repeat region for structured secondary content.

Photo notes repeat

gallery_notes turns the same image collection into a second presentation. This is the same App Connect lesson as elsewhere in the demo: one collection can feed multiple UI layers.

Detail map

detail_map binds one listing’s coordinates into a focused Leaflet map and marker, which keeps the location tied directly to the loaded record.

Amenities repeat

amenities is another repeated slice from the same loaded record, reinforcing how the detail page decomposes one record into several focused UI sections.

Inquiry handoff button

The Request Showing button passes the current listing id into the inquiry page. That is the workflow bridge between this routed detail page and the form page.

Wrap-up

The detail page completes the renewed demo pattern: route-driven loading, one detailed record, and several App Connect consumers built on top of it.

Next steps

Continue into the inquiry workflow, back to the listings page, or the wider App Connect index.

Demo walkthrough: Real Estate inquiry form

Focused walkthrough of the renewed inquiry page: Server Connect form posting, listing picker, calendar availability, validation, and success feedback.

Inquiry page mental model

The inquiry page is the demo’s form workflow example. It combines page-level data, availability helpers, and a Server Connect form that posts into the SQLite-backed inquiry pipeline.

Supporting data

The page loads listings and date helpers before the form is submitted.

Server Connect form

`inquiry_form` posts directly to `/api/inquiries/insert`.

Feedback on page

The same form surface exposes executing, success, and error states.

Load the listing picker data.

Guide the user with availability inputs.

Post the form and reflect the result in place.

Inquiry page opens

The walkthrough starts on views/inquiry.ejs, where the renewed demo combines calendar guidance with a Server Connect form workflow.

Inquiry editor is ready

The inquiry page is now active in Design View, so the Structure and Properties panels can follow the live page context.

Listings source for the picker

sc_listings loads the available listings so the form can present a live property picker instead of hard-coded options.

Showing calendar

The calendar gives users immediate context about availability before they fill the form, which makes the page feel guided instead of blank.

Server Connect form

inquiry_form is the page’s main workflow component. It posts to /api/inquiries/insert and exposes execution and feedback state directly to the UI.

Listing picker input

inp_listing_id shows how the form reuses the loaded listing collection to generate live select options and also accepts a prefilled query value from other pages.

Preferred date picker

The date picker mixes custom available dates and blocked dates, which is a practical example of App Connect enriching input controls with page-level data.

Submit button and feedback state

The submit button reacts to inquiry_form.state.executing, while the alert blocks above the form reflect success or failure after submission. That keeps the whole workflow visible on one page.

Wrap-up

The inquiry page completes the renewed demo’s workflow chain: browse listings, inspect a property, then save an inquiry through a guided App Connect form.

Next steps

Continue back to the detail page, the listings page, or the wider App Connect index.

Core components

Data-oriented building blocks: data components and common data sources.

Core components

Choose a Core components tour to start. These tours cover App Connect’s foundational data pieces—Variables/Arrays/Toggles, and common sources like Data Stores and derived datasets.

Data bindings & formatting

Expressions, bindings, pickers, and formatter chains for display-ready values.

Data bindings & formatting

Choose a Data bindings & formatting tour to start. These tours walk through building safe expressions with pickers, binding them to UI, and chaining formatters for display.