Re: [pgAdmin4]: Webpacking of static JS/CSS

​Hi Dave,

I didn't removed the vendor modules when i ran regression test cases, so
modules were being referenced from vendor dir and passed for me.
Now I have fixed path references and test cases are working.

Please find attached patch.

Thanks
Surinder​

On Mon, Jul 17, 2017 at 3:18 PM, Surinder Kumar <
surinder(dot)kumar(at)enterprisedb(dot)com> wrote:

> Hi
>
> I'm currently working on first TODO: "Automatically handle static and
> template JS files"
>
> As discussed with Ashesh, currently the paths to module id are written
> manually in webpack.config.js, instead the path defined in moudle's `def
> get_own_javascript()` should be used.
>
> So, we will be generating a paths.json file which will contain:
>
> 1. resolve > alias - path with reference to module id.(Static files)
>
> 2. externals - list of modules to be loaded dynamically on demand(Template
> files)
>
> 3. Shim module dependency
>
> 4. List of JS modules to be loaded in specified order.
>
> *Implementation:*
>
> To generate `paths.json` file, we will be using `Flask's test_client` to
> make an http request internally within the app context so we can call
> `current_app.javascripts` property and return the list of JS paths and
> write those into paths.json file and then use it in webpack.shim.js before
> the execution of `yarn run bundle` in `javascript_bundler.py`
>
> *For example:*
>
> @app.route('/get_script_paths')
> def get_script_paths():
> from flask import current_app
> from pgadmin.utils.ajax import make_json_response
>
> return make_json_response(data=current_app.javascripts)
>
> if config.DEBUG:
> with app.test_client() as client:
> import simplejson as json
> list_scripts = client.get('/get_script_paths')
> scripts = json.loads(list_scripts.data)
>
> javascriptBundler = JavascriptBundler()
> javascriptBundler.bundle(scripts['data'])
>
>
> This also needs little change in module dependency we defined using
> 'When': 'node_name' in `def get_own_javascripts(...)` method
> the module specified(name: module_name) is loaded when module given in
> `When` is expanded in node. Since we are using Webpack in which behaviour
> to load module is little different.
>
> Now in webpack we are using `imports-loader` to load specific modules. So
> this is how it should work.
>
> 1. First load all modules which do not have dependency on any node like
> 'about', 'dashboard', 'server-group', 'server' etc.
>
> 2. Load module such as `Databases` node first before its child nodes are
> loaded.
> Similarly load `Schemas` node before its child nodes are loaded as they
> are dependent on parent node.
>
> Thanks,
> Surinder
> On Wed, Jul 5, 2017 at 8:22 PM, Sarah McAlear <smcalear(at)pivotal(dot)io> wrote:
>
>> 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.
>>
> ​Templated JS will not be part of generated bundle JS, they will load
> externally( an extra request will be made to server For example:
> translations.js)
>
>>
>> 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.
>>
> ​Template JS cannot be bundled, so i extract the <Jinja> code from
> template files and put into a separate file - ABC.js (also moved template
> files to static directory) and then load ABC.js dynamically as dependency
> of other modules.
>
>>
>> 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?)
>>
> ​That file will always gets new content when loaded dynamically, the
> content is not cached.​
>
>>
>>
>>> *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?
>>
> ​No​
>
>>
>>
>> Thanks,
>>
>> George & Sarah
>>
>
>