Dashboarding in Flexmonster v3: A brand-new approach

As Flexmonster v3 continues to evolve, we’re taking a closer look at one of its main capabilities: dashboarding.

In v2.9, dashboarding was possible, but the component was not originally designed for it. Since dashboards are key to effective data visualization, making them a native part of Flexmonster became a major focus for v3. We redesigned the component architecture and logic to support dashboards out of the box.

Let’s look at the limitations of dashboarding in v2.9 and how v3 addresses them.

Limitations in v2.9

Each UI control in Flexmonster v2.9 was an independent instance with its own state and data handling. You could still create a dashboard with several Flexmonster widgets, but each one would load its own copy of the data and remain unsynchronized with the others.

The synchronization issue could be worked around by manually syncing controls using the available API.

Repeated data loading, however, couldn't be avoided. Because each control was self-contained, it loaded and processed its data independently, increasing CPU usage and memory consumption for end users.

Both limitations required an architectural solution.

What changed in v3

We rebuilt the v3 component from the ground up. In the revised architecture, a UI control no longer owns its data and state. Instead, they are managed as separate entities that can be shared across multiple controls.

Two key changes make this possible.

Dedicated data manager

To make data loading more efficient, we needed to:

• Eliminate redundant data requests.
• Reuse data that had already been loaded.

This wasn’t possible while each control managed its own data, so data loading was moved from individual UI controls to a dedicated data manager.

When the data manager first encounters a data source in the configuration, it registers the source, then loads, parses, and caches its data. Any other control connected to the same data source reuses data from the cache. As a result, multiple widgets require only one fetch-and-parse cycle for the same dataset, reducing resource usage.

State as a separate entity

In v3, controls no longer have an embedded state. Instead, each state is a separate object that the controls can attach to.

The state stores what widgets must share: the dataset and the slice. If you change the slice in one control, every widget connected to the same state updates accordingly.

At the same time, each widget maintains its own scroll position, expanded rows, and selected cells. This allows users to navigate different views of the same data independently while keeping their values consistent.

A dashboard is not limited to one state or data source. You can define as many states and data sources as needed—Flexmonster is fully equipped to handle such a use case.

Try dashboarding in v3

The synchronization logic that had to be implemented manually in v2.9 is now built in. You can focus on creating the layout that best suits your needs.

So what can be on a dashboard today? You can freely arrange pivot tables, flat tables, field lists for both table types, toolbars, and filters alongside other elements on the page. See the v3 documentation for an overview of the available widgets, and then explore control synchronization options.

More controls are on the way. Chart integration is in active development, and we also plan to support custom controls built on the Flexmonster architecture, so you can extend dashboards with your own data visualizations.

We’ll share more updates as these capabilities become available—stay tuned!