Full SPA Globalization

[Fabio]

Hi,

we are using Kendo Professional in an SPA application (only JS and WebApi) and we have a couple use cases of localization that we cannot achieve using documented methods and practices, so we are turning to this forum for help.

What we have now

We use mainly MVVM and already have a setup that allows us to load the correct culture/messages files and replace data-attributes that contain text with the updated strings; sometimes we have non-mvvm widgets that we call setOptions on manually.

We also have about a dozen custom widgets with texts in options like:

options: {
    name: "...",
    windowTitle: null,
    windowHeight: "50%",
    windowWidth: "50%",
    placeholder: null,
    inputPlaceholder: null,
    resultsPlaceholder: "Type something in the above field",
    ...
}

First use-case: complete app-localization

1. What is the right approach to localize widget options? Like input placeholders, windows titles, etc ...
2.  Is there a way to refresh widgets' data-attributes? (could calling setOptions for every widget, with the new parsed options from the element, be a solution?)

We have looked at stackoverflow, general blogs and this forum but no one seems to have a proposed solution. Only this thread was heading in the right way but it died years ago.

We don't want to put resources in viewmodels because we'd have to refactor many views and because a viewmodel should not be aware of what widget is currently rendered.

Second use-case: single view layout change

We have a custom view (with a single viewmodel) that should have different layout based on a user-selection, currently we are doing this:

1. calling kendo.destroy/unbind on the #view
2. replacing the innerHTML of the #view
3. calling kendo.bind(#view, viewmodel)

This is leading to big memory leaks and general bad performances after 3/4 executions.

What is the correct way of doing this?

Third use-case: single view/widget localization

Additionally, we have a single view that should be localized independently from the rest of the application; currently we are doing as indicated in theuse case nr 2 (destroy, update data-attributes, bind again); we know that this won't localize dates/currencies but we have only custom widgets in this view so it is not a problem for now.

This is causing the same memory leak as above that leads to several Megabytes (if not a Gigabyte) if used ram for the single chrome page if this function is called more than 6-10 times in a row, and the browsed becomes unusable after less than 10 times.

This could be replaced with a setOptions on all the fields if was implemented something like a kendo.refresh($element) that re-parses all data-attributes and calls setOptions.

 

Thank you in advance.

[Stefan]

Hello Fabio,

Apologies for the delayed response.

Regarding the three use-cases:

First use-case: complete app-localization.

1) The recommended way to widget options can be found in our documentation. 

http://docs.telerik.com/kendo-ui/framework/localization/overview

Additionally, you can use the messages properties of every widget, which are available through its public API. Check some examples, for messages properties that can be used in the Kendo UI Grid:

http://docs.telerik.com/kendo-ui/api/javascript/ui/grid#configuration-messages

2) Please refer to the following demo on how to change the options of the Kendo UI widgets dynamically. Have in mind, that data-attributes set in the HTML are taking precedence over the options from setOptions. You can clear the data-attributes from the HTML and then call setOptions:

http://demos.telerik.com/kendo-ui/globalization/index

Second use-case: single view layout change

Please check the recommended way to destroy the Kendo UI widgets. For the MVVM widgets, unbind the widget, and then destroy it. If the widgets are not destroyed properly, this can be the reason for the memory leak:

http://docs.telerik.com/kendo-ui/intro/widget-basics/destroy#destroy-widgets-created-via-mvvm

When destroying widgets created via MVVM, first call kendo.unbind() and then kendo.destroy(), as mentioned on the page above.

Third use-case: single view/widget

As this use case is connected to the second one, I can suggest using the same approach for destroying the widgets.

In order to investigate the issues for the second and the third use-cases, we will need a fully runnable example that reproduces them. This will also result in suggestions best suited for your application.

Regards,

Stefan
Telerik by Progress

 

[Fabio]

Hello Stefan,

we have managed to isolate the memory leak and now the performances are a lot better.

Sadly the "messages" approach is not possible in our environment because messages are more business-oriented than mere localizations ("No customers found" instead of "No data" for example) thus we implemented 2 alghoritms:

- when changing the entire template: unbind -> destroy -> load template -> setAttributes -> bind.

- when changing language: setAttributes -> setOptions

$(viewRootElement).find("[data-role]").each(function () {
    const $el = $(this);
    const widget = kendo.widgetInstance($el, kendo.ui);
    if (widget && widget.setOptions) {
        widget.setOptions($el.data());
    }
});

 

We are now having some problem with complex ObservableObjects but I will open another thread.

Thanks.

[Fabio]

For future reference, that code does not update correctly when attributes are rewritten because JQuery does not re-read the Data when from the dom.

This is the updated code:

$(viewRootElement).find("[data-role]").each(function () {
    const $el = $(this);
    const widget = kendo.widgetInstance($el, kendo.ui);
    if (widget && widget.setOptions) {
        widget.setOptions(kendo.parseOptions.call(kendo, this, widget.options));
    }
});