Chartbreaker
    Preparing search index...

    To use Chartbreaker, the following prerequisites need to be met:

    • No modifications to the prototypes of the built-in types Object or Array
    • The following javascript files provided with the release of Chartbreaker must be included:
      • bundleName.js

    Depending on the environment where ChartBreaker is used, some global configuration options might have to be set first.

    By default, all text from Chartbreaker is displayed in English. Text supplied by plugins is displayed using __i18n__-keys, which need to be replaced. To use another language, you first need to make it available to the library via a translation object.

    import { setLanguageData } from '@stock3/charting-bundle-chartbreaker';
    import deI18n from '@stock3/charting-bundle-chartbreaker/de.js';

    const language = 'de';
    setLanguageData(
    language, /*e.g. 'de', 'en'*/
    deI18n, /*{ content of translation object }*/
    );

    Afterwards, you can set the i18nLocale/i18nLanguage options on individual Controller instances.

    An example German translation is included in de.js. All strings are stored in a gettext compatible format that can be converted to and from common gettext .po files.

    First create an empty DIV-Element and attach it to the DOM. This is where the chart will appear. After that, an instance of Controller must be created. The DIV can be provided to Controller either directly via a reference to the HTMLElement object, or by its ID. If no width or height are provided to the constructor, the current size of the DIV is used. This means you can set the initial size of the chart using CSS properties.

    Controller is the main API interface of Chartbreaker; to manipulate a chart (e.g. to add, move or remove content) you should always use methods provided by the Controller if possible. It is important to note that, while other objects (such as Chart, or ChartSet) expose many of their own methods, they are mainly exposed for plugins and certain special use cases. In contrast to the stable Controller API, they may also change substantially between releases. This means that, generally, you should only ever call the methods provided by every instance of Object (like get and set) on any object that is not a Controller.