Designer Lag with large Data Model

When I have a data model with a large number of fields, Designer lags so much it becomes unusable. I believe I brought this up before, a few versions ago,and was told it was a known issue and was being looked into, but as of version 2024.2.3.23676 the problem still exists.

I have a CSV data file with 838 fields. Scrolling is impossible, toggling between Source, Design, and Preview takes about 8 seconds, etc. I do what I can, but most of the time I build my HTML in Notepad++ and paste in my work, avoiding the Designer UI as much as I can.

Until there is a fix, is there any “hack” that would stop Designer from constantly re-evaluating scripts while I’m building the document?

Hi @TGREER,

Is this triggered by the number of fields or by script evaluation? In other words, is the Designer also unresponsive if you have a large number of fields but no scripts?

The current Designer version evaluates scripts in design mode to look for runtime errors. This can affect responsiveness if there are many complex scripts, and the checks it performs are not even all that reliable. This is why we no longer do evaluate scripts in design mode in the version that is now in development, but I am not 100% sure if that is what we are talking about here. If it is, disabling scripts while editing would be the only (rather crude) workaround I can think of.

There are corresponding scripts for each placed data field, of which there are nearly 800. I’d like to test the “disable scripts while editing” approach. How does one do that?

Move the scripts to a folder, right-click the folder and select “Disable” - see the documentation here. When needed, right-click the folder and select “Enable” again. As I said, it is rather crude.

If there are that many search-and-replace scripts I think it would help a lot if you could refactor it to make use of Handlebars expressions instead. Depending on your data model this could be as simple as switching to Source mode, pressing Ctrl+F, checking “Regular expressions”, and replacing all occurrences of @(\w+)@ by {{$1}}. Then make sure “Evaluate Handlebars expressions” is turned on in the section properties, and remove the search-and-replace scripts.

However, for text with additional formatting extra steps would be required, and I fully understand that this is not always practical and may take too much time and effort for certain types of templates.

Yes, there are hundreds of fields/scripts that format as currency, and many scripts that concatenate multiple fields with prefix and suffix additions. Until the Handlebars implementation in the GUI allows for formatting, it is a loss of functionality. (I do the initial development but I support users who maintain the templates who aren’t comfortable with moving to handlebars until it is “fully” implemented in the GUI.)

Custom Handlebars helpers can be created through the GUI since 2022.2, although we did fix a usability issue in 2023.1. The wizard supports formatting and allows you to specify prefixes and suffixes:

I understand that refactoring search-and-replace scripts may not be trivial depending on the complexity of the template and data model, but it should offer significant benefits (particularly if there are many of those scripts) with no loss of functionality.

1 Like