This page is part of the External (Extended) Documentation

About the logging

Quokka system logs are used - and are necessary - both on the development stage and at the runtime.

Configuring the logger on the server side

The server-side code must define the logging namespace. As a rule, the global system object console is overridden in Quokka Platform (in some cases, however, such as testing environments, it isn't). If it is overridden, the logging namespace should refer to the classname of the component/module that will perform the logging. To configure the logger, determine whether the global console is overridden, and if yes, define your logging namespace - as in the example:

var console = global.console.fork ? // test if the global console is overridden
    global.console.fork('MyApps.Main') : // specify the logging namespace; in general, it is highly recommended that the logging namespace format be `Namespace.ClassName`
    global.console; // if console is not overridden, you may leave the logging namespace undefined, since this typically means the isolated usage of the module (for example, in a testing environment)

Configuring the logger on the client side

In the client-side code, classes have their own this.log methods, which perform the logging. The logging namespace for them is automatically determined by the system as the current class name.

Logging levels and methods

The following log methods are supported:

• console.log - normal level logging, the default logging level (use it for debugging as well)
• console.warn - warning level logging; use it for important messages and warnings
• console.error - error level logging; use it for errors only
• console.tinyLog - does not dump the full contents of the object into the log file, but allows the developer to 'query' the object through the Logger app (see 'Logger application' below)
• console.combine(data, function, [duration]) - collects data for its subsequent deferred logging; this method is convenient for the use in cycles. The data variable contains a data chunk to be collected (e.g. in a single loop). The function specified as function will be automatically invoked after the current function finishes, or after a delay if one is specified as duration in milliseconds. This function will receive all the collected data objects in a list for appropriate processing, upon which, function can properly log all the data.

Using tags

Tags can accompany messages being logged. These tags can be used for additional message filtering in the Logger application. A tag must start with '#' and be in the 'camel case' - for example: #myCamelCaseTag. Important: system events can contain a real object with data for subsequent processing.

Example of using tags:

console.log('#money, #input', {amount: 20})

Logger application

When the platform starts, a dedicated log manager application (Logger) starts at port 7777. It allows not only viewing log messages, but also manually 'querying' objects that have been logged in the console with the tinyLog method (see 'Log levels and methods' above).

Querying objects in the Logger application

The object querying is described below by an example. Descriptions follow the screenshots.

1 Open the Logger application at port 7777 as shown at the screenshot below. Find a logged object and press the (i) button near it.

The information pop-up window appears.

2 In the right pane of the information pop-up window, select a method of the object that you want to interact with. In our example, this is this.print.

3 The function call is automatically modelled in the bottom command line. Redefine the function arguments (in our example, this is 'test string') with your intended values.

4 Press Submit. The function call with specified arguments will be performed on the object instance that was previously logged.