Development Mode

yFiles for HTML includes a development mode version of the library that enhances your development process by simplifying debugging and providing a deeper understanding of the yFiles API. In development mode, the library includes type information for all yFiles for HTML types, their members, and the parameters of all methods. Additionally, the library offers auxiliary functions, such as inspecting and modifying the graph via the browser console.

It is highly recommended to run yFiles in development mode during development. This allows you to benefit from meaningful error messages and utilize runtime debugging tools that are only available in development mode.However, be aware that the development mode library is not redistributable and must not be published as-is. Additionally, the runtime debugging support introduces a performance overhead with each method call. See the deployment section for details on preparing the yFiles for HTML library for deployment.

To temporarily switch to production mode, you can manually enable it by including the following snippet in your HTML file before loading yFiles:

<script>
  window.process = { env: { NODE_ENV: 'production' } }
</script>

Setup

The development mode library is located in the lib folder, next to the regular library. It is distinguished by a dev suffix in its filename:

yFiles package root/
  demos-js/
  demos-ts/
  ...
  lib/
    yfiles-xx.x.x.tgz <-- regular library
    yfiles-xx.x.x+dev.tgz <-- development mode library

In development mode, the runtime type checks and graph inspection tools are enabled. Otherwise, the contents of the regular library and the development mode library are the same.

To check whether the yFiles for HTML library is running in development mode, check the browser’s console for a corresponding log message.

Type Checking

In development mode, the following tests are enabled for each method call and each invocation of a constructor or property:

1. Does the call have the correct number of arguments?
2. Are any arguments undefined?
3. Are the arguments of the correct type?
4. Does an explicit constructor implementation call a base class constructor?

The following tests are enabled when a class or interface is first used:

1. Does a class extend an interface instead of implementing it?
2. Does a class implement a class instead of extending it?
3. Does a class override a method or property that should not be overridden?
4. Is there cyclic class or interface inheritance?

Note that these tests will increase the runtime of your application.

By default, type checking is configured to immediately throw a standard JavaScript error for any problem found. This avoids delayed failures in your application, which, in JavaScript, can occur at any time.

In demos that use the yFiles demo framework, these errors are typically displayed in an error dialog like this:

Graph Inspection and Status Information

A common task during development and debugging is inspecting and modifying the graph and graph component in the browser’s JavaScript console. This can be useful, for example, to check the number of nodes and edges in the graph or to experiment with different settings for the user interaction.

The global function yfilesDebug() simplifies this task. It sets the properties window.gc and window.g to a graph component and its graph, respectively, and makes the last clicked item available in window.gc.clickedItem when available. Additionally, it makes yfiles accessible from the global scope (e.g., window.yfiles), shows details about the yFiles for HTML version and license, and disables catchErrors in yFiles error handling. Without yFiles error handling, most errors become uncaught errors and are easier to debug in the browser’s JavaScript debugger.

Its syntax is as follows:

function yfilesDebug(id? : string | Element) {}

The optional parameter id identifies the graph component. If it is a string, the graph component is looked up with the methods document.getElementById(id) and document.querySelector(id). If it is undefined, the element with the id "graphComponent" is used instead, if available. If the parameter is an element, the DOM hierarchy is traversed from this element upwards to locate the graph component. This is especially useful in conjunction with the variable $0 that is available in the debugging tools of some browsers.

Note that clickedItem is only available if the input mode of the graph component supports adding a clicked listener.

Custom Formatters

The development mode library of yFiles for HTML supports custom formatting of yFiles objects in the browser’s JavaScript debugger. Custom formatters display objects in a clear, easily understandable way when inspected in the debugger.

Currently, custom formatters are supported by Chromium-based browsers, most notably Google Chrome and Microsoft Edge, and Mozilla Firefox. In all these browsers, you must manually enable custom formatters via the settings of the developer tools (F12).