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

On Mon, Jul 17, 2017 at 4:52 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> No errors now, but do you know why JS tests are being skipped?
>
​No errors/warning in console even after settings `logLevel:
config.LOG_DEBUG`. I am still debugging.

>
> PhantomJS 2.1.1 (Mac OS X 0.0.0): Executed 4 of 216 (skipped 212) SUCCESS
> (0.085 secs / 0.046 secs)
>
> Thanks!
>
> On Mon, Jul 17, 2017 at 12:07 PM, Surinder Kumar <
> surinder(dot)kumar(at)enterprisedb(dot)com> wrote:
>
>> ​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
>>>>
>>>
>>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>