Demos

[admin]

Hi,

For dynamically updating the dropdown’s data source, please refer to https://www.htmlelements.com/demos/grid/editing-cascading/.

Regards,
Markov

[admin]

Hi,

Smart Editor can work offline in a JavaScript PWA, but the recommended approach is to make the PWA responsible for offline support, not the editor itself. The Smart UI team recommends bundling all editor assets locally and using a Service Worker with a cache-first strategy so the editor loads without a network connection.

Example setup:

Register the Service Worker:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

A simple cache-first strategy:

const CACHE = 'support-dashboard-v1';

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      return cached || fetch(event.request);
    })
  );
});

Regards,
Markov

[admin]

Hi,

What is the idea of the provided code? What do you try to achieve with it? In JS, it’d be better to use setAttribute and getAttribute to get/set attributes. If you set custom attributes, it’s better to use data- notation.

Regards,
Markov

[admin]

Hi,

The recommended approach for large datasets is to take advantage of its performance features rather than treating dataSource as an unlimited client-side array. HTMLElements specifically documents UI virtualization and server-side loading as the approach for large datasets, allowing thousands of points to be handled without rendering everything at once.

The practical pattern is:

Keep the dataset on the server and load only the data needed for the current view/range.
Use aggregation/downsampling server-side when you have millions of raw records. For example, return hourly/daily aggregates rather than every individual event.
Use Smart.Chart’s zoom/range navigation so the user can progressively inspect a smaller portion of the dataset.
Avoid repeatedly replacing a huge dataSource during filtering; update the data in appropriately sized chunks and call refresh() when needed.
Prefer Canvas rendering for very large visualizations where appropriate; Smart.Chart supports both SVG and HTML5 Canvas rendering.
Be careful with expensive features such as animations, labels, and tooltips across thousands of points. Disable or limit them when they aren’t essential.

So, for an admin dashboard, the architecture I’d use is:

database → server-side filtering/aggregation → paged/viewport-sized data → Smart.Chart → zoom/drill into finer-grained data

If your current edge case is specifically 100k+/1M+ points in dataSource, the important distinction is whether you’re trying to render all those points or merely query them. Smart.Chart’s large-data story is much better when the browser only receives the data required for the current viewport rather than the complete raw dataset

Best regards,
Markov

[admin]

Hi,

It is possible. By using the saveState and loadState methods. They include the current state of the Grid so you can save it either in a variable or local storage and reload it when you need it.

Regards,
Markov

[admin]

Hi Alex,

Yes, just set its value to an empty string like this – editor.value = ”;

Regards,
Markov

[admin]

For Smart Gantt, the cleanest approach is to enable the built-in editing features and make your data model the single source of truth.

A typical production pattern is:

Enable the required editing options (task editing, drag-and-drop, resizing, etc.) in the Gantt configuration.
Listen for the component’s edit/change events (such as task updates, resize, or move).
Update your application state or send the changes to your API from those event handlers.
When the server responds, update the underlying data source instead of forcing a full component refresh. This keeps the UI and your data synchronized.

If you’re seeing changes only after a manual refresh, it’s usually a sign that the component’s data source isn’t being updated reactively after edits. Rather than recreating the Gantt instance, update the affected task in your data model and notify the component of the data change using the framework’s reactive state management (or the component’s data update API, depending on your setup).

This event-driven approach scales well for both static and API-backed data, minimizes unnecessary re-renders, and provides a much smoother editing experience in production.

Regards,
Markov

[admin]

Hi,

For Smart.DateInput, the cleanest pattern is to keep the application state as the single source of truth and treat the component value as a controlled input. The component should handle user interaction, while Redux/Vuex/Pinia (or another store) owns the selected date value.

A typical flow is:

1. Store the date value in your global state.
2. Bind Smart.DateInput’s value to that state.
3. Listen for the component’s change event.
4. Dispatch an action/update the store when the user changes the date.
5. Let the store update flow back into the component.

Example with Vue-style state management:

<smart-date-input
    :value="selectedDate"
    @change="onDateChange">
</smart-date-input>

computed: {
    selectedDate() {
        return this.$store.state.filters.date;
    }
},
methods: {
    onDateChange(event) {
        this.$store.commit('setDate', event.detail.value);
    }
}

Regards,
Markov

[admin]

Hi Alex,

For Smart.Gantt, the cleanest approach is to make responsiveness part of the layout strategy rather than trying to resize the component manually on every window event.

A recommended pattern is:

1. Put Smart.Gantt inside a responsive container
– Use a parent element with flexible sizing (width: 100%, controlled height, flex/grid layout).
– Let the component calculate its available space from the container.

2. Handle resize events through a ResizeObserver
– Prefer observing the Gantt container instead of listening directly to window.resize.
– This also handles side panels, dashboard layout changes, and dynamic navigation areas.

Example:

const container = document.querySelector('#ganttContainer');
const gantt = document.querySelector('smart-gantt');

const resizeObserver = new ResizeObserver(() => {
    gantt.refresh();
});

resizeObserver.observe(container);

Regards,
Markov

[admin]

Hi,

The cleanest way to implement undo/redo for Smart Gantt task edits is to treat every edit as a command with a before/after state, rather than trying to restore the entire chart state.

Keep a history stack containing the changed task data:

– Before a task edit starts, store the original task state.
– After the edit completes, store the new state.
– Undo applies the old state.
– Redo applies the new state.
– Keep server persistence separate: when an undo/redo action changes a task, send the resulting task state back to the API so the backend stays synchronized.

A typical structure looks like:

const undoStack = [];
const redoStack = [];

function saveTaskChange(oldTask, newTask) {
    undoStack.push({
        oldValue: { ...oldTask },
        newValue: { ...newTask }
    });

    redoStack.length = 0;
}

function undo() {
    const action = undoStack.pop();

    if (!action) {
        return;
    }

    gantt.updateTask(action.oldValue.id, action.oldValue);

    redoStack.push(action);
}

function redo() {
    const action = redoStack.pop();

    if (!action) {
        return;
    }

    gantt.updateTask(action.newValue.id, action.newValue);

    undoStack.push(action);
}

Regards,
Markov

[admin]

Hi linda,

In our case, we keep the grid state (filters, sorting, pagination, etc.) synchronized with the Angular Router using query parameters, so users can navigate away and back without losing their current view.

If you’re seeing performance degradation with larger datasets, I’d first check whether route changes are causing the grid component to be recreated. Also, make sure you’re using OnPush change detection, trackBy for row rendering, and server-side paging/filtering if the dataset is large. In most cases, routing itself isn’t the bottleneck—it’s the component lifecycle or unnecessary grid re-renders triggered by navigation.

Regards,
Peter

[admin]

Hi Damir,

It does not matter whether the grid is initialized or not, it’s important to have the dataFields property of the dataSourceSettings object set and the columns to point to the data fields in the data fields collection. This way, the data will be readable and stored.

Regards,
Markov

[admin]

Hi Emily,

The best way is to look at the https://www.htmlelements.com/demos/grid/leads-template/ and how we define the templates with buttons in the first column. By using this approach there would not be unnecessary re-renders.

Regards,
Markov

[admin]

Hi,

You can use the Chart’s refresh() method which basically redraws the chart taking into account data changes.

Regards,
Markov

[admin]

Hi,

Yes, it is possible to enable / disable features when you create the editor and also dynamically. Please, refer to https://www.htmlelements.com/docs/editor-api/ for additional details about the available options.

Regards,
Markov

[Author]

Posts