CLDR-15239 add cldrDebug for nimble front end config

[srl295]

• New optional property CLDR_FE_DEBUG={} which is evaluated on the client side
• New module cldrDebug for encapsulating calls to this property
• Example usage in the test panel ( /cldr-apps/v#test_panel/// )

CLDR-15239

• This PR completes the ticket.

FYI it ought to reload when you save bootstrap.properties but that didn't work for me, it produced an error. restarting the server (hitting r on the liberty:dev console) reload the properties file.

The benefit is that these switches never need to be checked in anywhere.

ALLOW_MANY_COMMITS=true

[srl295]

view of the test panel with this change

view of the test panel with CLDR_FE_DEBUG={specialFlag:true} in bootstrap.properties

[btangmu]

Interesting! It would help to have more concrete examples of how we would use this. One thing that's not clear to me is what are the pros/cons of configuring this on the back end such as in bootstrap.properties (btw is that a conventional name? at first I thought it was referring to the bootstrap library). Currently we commonly have debug booleans that are private to individual js modules. Would those move to bootstrap.properties?

[macchiati]

It's a bit hard for me to tell (js is very rusty), but this does allow for a map, right? eg

{specialFlag:true showStatus:full ...}

[srl295]

It's a bit hard for me to tell (js is very rusty), but this does allow for a map, right? eg

{specialFlag:true showStatus:full ...}

It's a JS object, so it would be:

{specialFlag:true, showStatus:"full", /* … */}

[btangmu]

If it has to be squashed into a single line it might be a little cumbersome:

CLDR_FE_DEBUG={someProperty:true, anArray: [4,5,6], CLDR_TABLE_DEBUG: true, DEBUG_SHOWER: false, DEBUG_LOCALE_STAMP: false, CLDR_VOTE_DEBUG: false, ...}

[btangmu]

I do like the benefit of being able to change the settings on remote servers without editing the source

[btangmu]

I wish we could avoid embedding js inside html inside java like this

[srl295]

I wish we would delete SurveyTool.java and make it a static html file. We could probably get webpack to assemble this into the bundle. I did it this way to make it easier to understand and to use. if unset, there's no other effect.

[btangmu]

there's no checking whether feDebug is a well-formed json string -- that seems like a drawback to storing it in a properties file, along with having to squeeze it onto a single line

[srl295]

It's not meant to be JSON, it's arbitrary js code, which is shorter to write (see example). That's a lot harder to validate.

[srl295]

Interesting! It would help to have more concrete examples of how we would use this.

There's an example in the PR and in the jsdoc, reproduced and expanded here:

import * as cldrDebug from "../esm/cldrDebug.mjs";
…
    const { specialFlag } = cldrDebug.all();


    if (specialFlag) { 
        // do something
    } else {
        // specialFlag is not set or is false
    }

One thing that's not clear to me is what are the pros/cons of configuring this on the back end such as in bootstrap.properties (btw is that a conventional name? at first I thought it was referring to the bootstrap library).

• bootstrap.properties is not added to the repository. It's local to each server. Perhaps that wasn't clear.
• bootstrap.properties is documented here and is unrelated to the bootstrap library. If you don't already have this file, you can edit cldr/tools/cldr-apps/target/liberty/wlp/usr/servers/cldr/bootstrap.properties
• Right now you have switches that you are setting right in the library code, where you have to commit a change to make a change.
• This allows these switches to be turned on and off on a per-server basis. Need to debug something, just update bootstrap.properties and restart. Then, for production and smoketest, they are always off (unless someone turns them on on the server of course)

Currently we commonly have debug booleans that are private to individual js modules. Would those move to bootstrap.properties?

I would imagine that instead of const CLDR_TABLE_DEBUG = true; in a library it would be:

const {CLDR_TABLE_DEBUG} = cldrDebug.all();

And then if you wanted to turn it on, you edit bootstrap.properties.

[srl295]

on the servers the file is /var/lib/openliberty/usr/servers/cldr/bootstrap.properties

[srl295]

If it has to be squashed into a single line it might be a little cumbersome:

CLDR_FE_DEBUG={someProperty:true, anArray: [4,5,6], CLDR_TABLE_DEBUG: true, DEBUG_SHOWER: false, DEBUG_LOCALE_STAMP: false, CLDR_VOTE_DEBUG: false, ...}

yes. The false ones can be omitted, though.

[srl295]

also i named the module cldrDebug instead of cldrConfig because it could perhaps have routines for measuring timing, etc, and also to make it clear what its purpose is.

[btangmu]

"bootstrap.properties is not added to the repository" -- yes I understood that and I do see the benefit of that

[btangmu]

how hard would it be to have a file stdebug.json (maybe in the same location as bootstrap.properties, anyway not part of the git repo), and serve it separately in response to a request from the front end?

[btangmu]

"I wish we would delete SurveyTool.java and make it a static html file" -- yes! What stands in the way of simply putting an index.html in the webapp folder?

One complication is SurveyTool.getCacheBustingExtension()... we always use webpack now; between open liberty, nginx, and webpack there must be some straightforward way to do cache-busting without using java to write html!

[srl295]

how hard would it be to have a file stdebug.json (maybe in the same location as bootstrap.properties, anyway not part of the git repo), and serve it separately in response to a request from the front end?

that does add another round trip query! It can't serve from that directory. so it would require a change in packaging. as mentioned above, webpack might be able to include such a file, but we'd need to handle the case where that file is missing.

[srl295]

"I wish we would delete SurveyTool.java and make it a static html file" -- yes! What stands in the way of simply putting an index.html in the webapp folder?

Not a lot, actually.

One complication is SurveyTool.getCacheBustingExtension()... we always use webpack now; between open liberty, nginx, and webpack there must be some straightforward way to do cache-busting without using java to write html!

and i wouldn't use that at all, but I'd have that be the responsiblity of the bundler (webpack) which can do that extension mangling itself.

[srl295]

how hard would it be to have a file stdebug.json (maybe in the same location as bootstrap.properties, anyway not part of the git repo), and serve it separately in response to a request from the front end?

that does add another round trip query! It can't serve from that directory. so it would require a change in packaging. as mentioned above, webpack might be able to include such a file, but we'd need to handle the case where that file is missing.

Actually, I think I found out how to do this (as part of the front end monitoring stuff). I'll see what I can do.

[srl295]

@btangmu any interest in this as an improvement, and then improve the install instructions later?

[srl295]

I'm going to include a similar path for datadog tracing