Console

The Console lets you try out a piece of Ninox code before putting it in your database: you write it, run it, and see the result right away.

The Console has existed since version 3.1. The debuggers, "Check", "Format code" and JavaScript autocompletion arrive with version 3.2.0 (beta).

The Console tab lets you write Ninox code and run it immediately, as in an interpreter, then debug it: checking without running, step-by-step debugger, replay debugger.

The tab is reserved for administrators. It only shows its icon, a terminal window, between the Debug Tracer and Errors tabs; its name appears on hover. It can be switched off in the Ninext Settings, "Script Manager" section.

Choosing the execution context

The code runs in the context of a record, like a formula of its table — or without a record:

ContextEffect
No envNo record: the code is evaluated like global code.
Live recordThe record displayed in the foreground in Ninox. The context follows you as you switch records.
RecordA record you choose, among those open in Ninox's windows, or through Pick another record…, which opens a picker (table, search, list of records).
FormulaThe record returned by a formula you write, for example record(Customer, 12). The formula is evaluated again at each run.

The context bar shows the chosen context; its cross resets it.

Writing the code

The Console editor offers:

  • Ninox syntax highlighting;
  • autocompletion of functions, tables, fields and keywords, as you type or with Ctrl + Space;
  • underlining of errors (red squiggle) and warnings (amber dotted line) as you type, with a ⛔ or ⚠ marker in the margin;
  • highlighting of the other occurrences of the selected word;
  • a Copy button, in the top right corner, when you hover the editor;
  • a handle, below the editor, that sets its height.

JavaScript autocompletion in native blocks

Inside a #{ … }# block, the Console offers the same typing help as the browser console, adapted to what the block actually receives:

  • the visible Ninox variables and parameters, in their JavaScript form, with their type;
  • local Ninox functions, ui, database, and callback when the block is declared :callback or :async;
  • after a dot, the object's members — for a record, the names of its fields; a name that is not a JavaScript identifier is inserted in the form ['…'];
  • in the #{: header, the types; after :nid( or :rid(, the list of tables.

This help only exists in the Console.

Running the code

The three run modes of the Console

The green Run button runs the code, as does Ctrl + Enter (⌘ + Enter on Mac). Its chevron offers three modes:

ModeEffect
RunRuns the code in one go and displays the result.
ReplayRuns the code once, then lets you walk through its execution forwards and backwards.
Step by stepRuns the code one instruction at a time, stopping where you decide.

The chosen mode is remembered; the button takes its name, and the shortcut launches that mode. Choosing Step by step or Replay immediately brings up, below the editor, that debugger's bar, its commands in place but turned off: nothing runs before you launch it. After a successful run, the code is reformatted in the editor; the history keeps the text as you wrote it.

Reading the results

Query result in the Console

Results pile up, the most recent at the top; the Console keeps twenty of them. Each result shows its type, its context, its date, its time and its execution time; a click on its header collapses it, its cross removes it, and Clear empties the list.

  • A simple value is displayed with a Copy button.
  • A record is displayed with a button that opens it in Ninox, and its fields as a tree.
  • A list of records is displayed as in Ninox views: conditional formatting, photo thumbnails, color chips, column widths. One tab per view, in Ninox's order; the views you are not allowed to see are hidden. When the tabs do not all fit, the … button ("More views") lists the ones out of sight. A click on a row opens the record, and rows load 100 at a time as you scroll.
  • Objects and lists are displayed as an expandable tree; every value can be copied, and a record opens with one click.
  • A text containing JSON is displayed as is; the Tree button unfolds it on demand.
  • A text longer than 100,000 characters is displayed instantly, truncated, with Show all; Copy always copies the whole text.

During a long evaluation, a waiting indicator appears.

Checking without running

Check (Ctrl + Shift + Enter, ⌘ + Shift + Enter on Mac) compiles the code without running it: no effect on your data. It reports Ninox's errors and warnings, and applies Ninext's own checks:

  • a user-interface function or a native block placed in a do as server, where they would have no effect;
  • a variable declared then never read;
  • the JavaScript syntax of native blocks;
  • the HTML and CSS passed to html().

The verdict is shown in the bar, and the cursor moves to the first diagnostic. When two types do not match, the explanation says which ones. If the code is valid, it is formatted.

Formatting the code

Format code (Ctrl + Shift + F, ⌘ + Shift + F on Mac) tidies up the code, without running it: indentation, spaces around operators, field names written the way Ninox displays them. The JavaScript of native blocks #{ … }# is formatted too: a block written on a single line unfolds below the line that holds it.

Code containing errors must be fixed first; and if formatting might lose part of the text, it is not applied, and you are told so.

The same button exists in Ninox's script editors: it appears in the top right corner when you hover the editor, and the keyboard shortcut works there too.

The step-by-step debugger

Step-by-step debugger: breakpoint and variables

Breakpoints

  • A click in the left margin, or on the line number, sets a breakpoint (red disc); a second click removes it.
  • A right-click, or Alt + click, opens the Break condition panel: execution only stops there if your condition is true, for example i > 10. The same panel lets you Disable the breakpoint without losing it (gray ring), then Re-enable it. A conditional breakpoint is an amber disc.
  • Conditions are evaluated without access to the database, with simple functions (count, length, text, upper, lower, contains…). If a condition cannot be evaluated, execution stops for safety.
  • As soon as an active breakpoint is set, Run stops there too, then carries on step by step.

The commands

The session starts paused on the first instruction.

CommandEffect
Next stepRuns the instruction and stops before the next one.
Sub-stepMoves forward one sub-expression at a time, showing the resulting value. On a function call or on a schema formula field, steps into its code.
Step outFinishes the current function and returns to the caller.
ContinueRuns to the next breakpoint, or to the end.
StopAbandons the execution.

When the bar is narrow, the commands only show their icon; their name appears on hover. The information button (ⓘ) of the bar unfolds the debugger's instructions, and the cross, which appears once the execution is over, closes its panel.

When execution steps into a function or a formula, its code opens in a stacked frame, which slides in from the right as in Ninox. You can set breakpoints there: they are stored by function name, apply to all the calls of that function and to the following runs, and disappear when the page is reloaded. The frame of a schema formula bears the label formula. A handle, on the left edge of a frame, sets how much of the frame below it covers. A #{ … }# block counts as a single step.

Variables

At each step, the Variables known at this step panel gives the value and type of every variable; a value can be expanded and copied, and a record opens with one click. Variables that exist but are out of scope appear in gray.

Good to know

Execution is really suspended at each pause, and the database keeps living meanwhile: other users, the API, triggers. What has already been executed stays applied, even if you stop. A pause of more than ten minutes ends the execution.

The replay debugger

The code runs for real, only once and in one go. You then walk through its execution forwards and backwards, with the step-by-step commands — Next step, Sub-step, Step out, Continue — plus First step and Previous step. The list of steps gives the value obtained at each one; a click on a step takes you straight there. Replay counts in big steps: one per executed instruction, and one per loop iteration, which gives the value of the loop variable. The sub-steps, indented, bear the number of their big step (3.1, 3.2…) and are counted separately ("+6 sub-steps"); Step out also goes up from a sub-step to the big step that carries it. The stacked frames and the variables panel are the same as in step-by-step mode. Ideal to understand what happened without running the code again.

Limits:

  • a record appears in its current state, not in the state it was in when the code ran;
  • the condition of a conditional breakpoint is not replayed: replay always stops there;
  • beyond 10,000 steps, the recording is truncated.

Both debuggers refuse code that contains errors, and report them as Check does.

Debugging from the Ninox editor

When you hover a Ninox script editor, the Debug in the Console button appears in the top right corner. It opens the Console and takes your code there, without running it, with the current record as its context: if there is no active record of that table, the record picker opens on that table. From the global code, the context is No env, and only the function where the cursor sits is taken.

The code taken there replaces the Console's code, and its breakpoints.

History, and your work that follows you

  • The History button lists the last 50 commands; Alt + ↑ and Alt + ↓ browse them from the editor. A click reloads the code and its context, replacing the current code and its breakpoints.
  • When you hover a history line, a trash can deletes it.
  • Code taken from the history is rebuilt in Ninox's current language: "Id" becomes "Nr" in German. Code recalled after a language change therefore always compiles.
  • On startup, the Console brings back your last code, its context, its results and its breakpoints — each user gets their own on a shared computer.
  • For an administrator, the history and the last code also follow from one computer to another, and survive clearing the browser's data.

Warning

This history is saved, unencrypted, in the plugin settings, which every user of the database loads. Do not leave a password or an access key in it.