Debugging in VBCS is different from debugging in a traditional JavaScript framework. You’re working in a low-code environment where much of the runtime behaviour is generated, which means the usual “read the code” approach doesn’t always work. Here’s a systematic approach.
The three-layer debugging model
VBCS bugs generally live in one of three layers:
- UI layer — binding expressions, component configuration, layout issues
- Logic layer — action chain errors, variable scope problems, incorrect conditions
- Data layer — REST call failures, schema mismatches, unexpected response structures
Identify which layer the problem is in before you start changing things.
Browser developer tools are essential
Open them by default. The Console and Network tabs in Chrome or Edge DevTools are your primary debugging instruments — more useful than the VBCS designer for anything beyond simple layout issues.
Console tab: VBCS logs runtime errors, action chain failures, and component warnings here. If something isn’t working, the console usually tells you why.
Network tab: Every REST call your app makes appears here. Check: is the call being made? What’s the response? Is the response structure what you expected?
Debugging action chains
VBCS’s action chain debugger (the bug icon in Design mode) lets you step through action chain execution and inspect variable values at each step. Use it for complex chain logic.
For simpler cases, add a JavaScript action with console.log:
console.log('After REST call:', $chain.results.callRestAction1.body);
console.log('Current variables:', $page.variables);
Remove these before publishing.
Binding expression debugging
When a [[ expression ]] binding produces unexpected results, isolate it: temporarily bind it to a Text component to render the value on screen. This is faster than guessing.
For complex expressions, break them into intermediate variables. Instead of one long expression on a component binding, compute intermediate values in an action chain and store them in page variables.
REST response schema mismatches
The most common data layer bug: your service connection schema doesn’t match the actual API response. The API might have added or renamed a field since you last introspected it.
Fix: in the service connection editor, fetch a live response and compare it to the stored schema. Update the schema if they differ, then trace which variable assignments in your action chains reference the changed field names.
The reproduce-first rule
Before changing anything to fix a bug, confirm you can reliably reproduce it. A fix applied to a bug you can’t reproduce is just a change that might break something else.