TypeError: Cannot read properties of undefined (reading 'anvil$designerPath')

[oluwademiladeoyebanj]

What I’m trying to do:
I recently logged back into a project after a few weeks away and my design window on any of my two main forms are producing this error as a pop-up:

This wasn’t happening prior to today’s log-in and closing the pop-up spawns another one.

In my ‘Designer Output’ I’m getting this on repeat as well:

The error says:

• [An internal error has occurred] - see browser console for more details
• TypeError: Cannot read properties of undefined (reading 'anvil$designerPath') at HTMLDocument.S (https://anvil.works/runtime-new/runtime/dist/designer2.bundle.js?sha=786a8109df7707bf6623:612:17111)

Used browser to inspect and it pretty much said the same thing:

but I did find some other warning further down:

Hobbyist developer so maybe I missed something but this seems like a server side issue? Any help would be appreciated

[stucork]

ah looks like you’ve been hit with an issue where calling an alert in the designer now works

We’ll look at that

If you keep clicking the ok button, eventually your form will load

You seem to have a bunch of components that in their init methods call a server function and then raise an alert if the call fails
The call fails when executed in the designer

Maybe you have 12 such components
and so 12 alerts to click

A way to avoid this would be to use the anvil.designer.in_designer

import anvil.designer

class MyForm(MyFormTemplate):
    def __init__(self, **properties):
        ...
        if not anvil.designer.in_designer:
            self.do_init_server_call()

    def do_init_server_call(self):
        ...
    

[oluwademiladeoyebanj]

Hmm. I see.

1. Is there a way to locate what part of my code is causing this? I’m not sure if it’s the loaded form or one of the forms embedded within it.
2. When you say “we’ll look at that” do you mean I can just close warning for now and eventually they will hopefully go away from the fixes on your end?
3. If I were to attempt to publish this application, can I assume the same would happen for users?

[stefano.menci]

@oluwademiladeoyebanj

If I were to attempt to publish this application, can I assume the same would happen for users?

The problem is when you “look” at the form in the IDE, not when you run the app. Forms today are alive even when the app is not running, that is they do run their init code so they can reflect the values of their properties in the form designer.

This was not the case in the past. Forms used to render as black boxes. Custom component were rendered in their default state, regardless of the values of their properties, and only native components were able to reflect the values of some properties.

So, an old app that was working both in the IDE and in production, still works in production, because nothing has changed there, but when you open it in the IDE, you may see messages printed in the console, alerts popping up, or forms showing up as a rectangle with an error message rather than a form with its components.

The correct fix is for you to use the in_designer as suggested by @stucork to prevent the execution of code that would fail while the app is not running.

I have the same problem when forms make a server call that requires user authentication and fails when the app is not running and the user is not authenticated. For example, if a form needs the values to show in a drop down, I use in_designer to decide whether to call the server function and get the correct values for the current user or to define dummy values to use in the IDE.

@oluwademiladeoyebanj

When you say “we’ll look at that” do you mean I can just close warning for now and eventually they will hopefully go away from the fixes on your end?

I have the feeling that they will look at the internal error. Internal errors are a way for the app to say “something went wrong, but I don’t know what”, and they should always be managed better by Anvil, not by us, at least with a more useful message.

---

As a side note, a form that makes 12 server calls at loading time is going to slow down your app to a crawl! If the calls come from the same place, you should consolidate them in one call that returns a dictionary with the 12 values. If they come from 12 different components as suggested by @stucork, you should figure out a way too either preload and cache, or lazy load (and still cache).

[oluwademiladeoyebanj]

Thank you for your reply. I believe it may be my plotly graphs which display different pieces of information and are created as their own forms and then dragged and dropped into the design window. The load times are quite long for that page so would a good lazy mode method be to maybe load them on scroll?

[stefano.menci]

If you always have the same 12 graphs, then make one call when the form loads to get the data from all the 12 graphs in one shot and put it in a global variable defined in a module. You could store it in the form, but it’s cleaner to use a module that can be imported by all forms.

If the slow part is the data collection part rather than the round trips, then you could make it lazy, triggered by something fancy like detecting the scroll bar events or when a graph becomes visible, but that requires knowing those events and playing with a few JavaScript lines, or something simpler like a timer that postpones the loading of the graphs at the bottom by a few seconds.

EDIT
I reread you question and would like to add something:

I would:

• convert the graph forms into custom components
• add a graph_data property which, when assigned, updates the graph
• the form should load the data for the 12 guys in one shot, then set the property one by one

[stucork]

1. Do a global search for the error message you’re seeing in the designer. That’ll show you all the forms that have that issue.
2. As to the action we’ll take on this it really depends what we think the right behaviour should be when running an alert in the designer. So I wouldn’t wait.
3. I think already answered