We have a lot of clientside functions in our app, most defined with multi-line strings in the python modules themselves. It appears that this type of function definition is added to the page as an inline script. Therefor, we have A LOT of definitions on the html page. I’m wondering what are the merits of cleaning all this up and moving these js functions to a static directory and loading them via the external_scripts argument (and then referring to them via ClientsideFunctions) vs just leaving them where they are. I know that regardless of where they live a user will be able to see it (either in a scripts directory or just by looking at the page html); however, it certainly makes me feel “cleaner” to tidy this up and remove all of those inline scripts.
Also, interested in hearing what other ways people are dealing with organizing lots of js functions.
PS, we use a lot of clientside functions primarily because I think the network overhead is wasteful to do things like open and close a modal or something similar.
I would say that the #1 reason why you should externalize the functions is to get a more organized project and benefit from the syntax coloration that code editors provide if you add your code in a proper .js file.
Note that having all the code in a separate JS file or added in the HTML page should have no impact on performance at all (in terms of loadin time, or execution time).
That is based on my experience, 50% of an app being clientside callbacks
you don’t even need to do this - just drop the .js in the assets folder and it’ll be loaded automagically.
Otherwise, I fully agree with @spriteware’s post. Having my JS functions in an actual .js file enables better IDE usage and makes the app cleaner as a result.
Having worked on a Dash app with tens of thousands of LOC hundreds of clientside callbacks, I find it conceptually simpler to just trick my IDE into realizing that these multiline strings are JS,.
Ultimately decided to move everything to a “static” directory and then build out an easier to work with structure for our js files. I agree, having the IDE handle the native .js file is a lot easier to work with. I had not heard of TreeSitter and appreciate that as well!
In case any one is curious here are some interesting/boring tidbits…
It appears that all functions ultimately have to live within the dash_clientside namespace (and of course a sub-namespace of our choosing) to comply with ClientsideFunction(). There is no more delineating into further namespaces at this point, which would be helpful for organizing on our end but not terribly important.
We use dynamic generation of component IDs. We had been using f-strings in python to handle these names but now have opted for a js_id store which has all of the required ids we would need inside the javascript. The store is pulled in via a State parameter.
Instead of putting the js files in the “assets” directory and to help us better organize, we opted for a new “static” directory. We then built a simple tool which compiles a list of all external .js files inside this new directory and adds them to the “external_scripts” argument when we instantiate Dash.
We handle a few Dash servers behind a reverse proxy for our application and this seemed to make the most sense for now. Looking forward to refactoring it when it no longer works!
