Re: [pgAdmin4]: Webpacking of static JS/CSS - Mailing list pgadmin-hackers

From Sarah McAlear
Subject Re: [pgAdmin4]: Webpacking of static JS/CSS
Date
Msg-id CAGRPzo-i9MBZZVB32akaUo-Hos1pgRKwNP9_-k7Qkemk7M8W+w@mail.gmail.com
Whole thread Raw
In response to Re: [pgAdmin4]: Webpacking of static JS/CSS  (Surinder Kumar <surinder.kumar@enterprisedb.com>)
Responses Re: [pgAdmin4]: Webpacking of static JS/CSS
List pgadmin-hackers
Hello,


​Things to discuss:

How to differentiate between a static and template JS
​​
.

What is the advantage of webpacking templated JS? It seems as though this creates a system in which the bundled dependencies have to refer back to the backend to load the templates. 

If there is a performance win in packing templated JS then looking at it makes sense.  Otherwise it may make sense to put off until it is clear that the templated files should be dealt with by either de-templating them or bundling them where there is a clear reason.

However, we're wondering about possible performance penalties with templating larger files (as opposed to templating on-demand.) Since jinja templates can execute arbitrary python, this could get time expensive and further slow things like initial page-load.
Another concern is: what happens when a template gets out of date (e.g. if browser.js had previously filled in the content for 'panel_item.content' and had been cached, would it render a new version with the new values when needed? Or is it possible that we would get old content?) 
 
Taks remaining:

​1. ​
Fix local variables which are declared without using var, have to check in each file
​ by​
 running eslint (For now, i will fix only errors which are giving error in browser).

​2. ​
Move non-template files from ’templates’ to ’static’ directory. List of
​ pending​
 modules is here: 
  • Tools (mostly all modules - 9 modules) 
  • Browser nodes - 3 modules(resource group, roles, tablespace)
  • ​About
    ​​
Also can we move 
​'​
dashboard, statistic
​s​
, preferences and help
​'​
 modules inside misc to preserve modularity as pgAdmin is modular
​ ?​

Is there anything from a organization stance you discussed in the previous email that needs to be done to make this usable and consistent?


Thanks,

George & Sarah 

pgadmin-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: [pgAdmin4][Patch]: Refactor of the History Tab
Next
From: Matthew Kleiman
Date:
Subject: Re: [pgAdmin4][Patch]: Refactor of the History Tab