Codecov Report

Attention: Patch coverage is 69.38776% with 30 lines in your changes missing coverage. Please review.

Project coverage is 69.79%. Comparing base (e919778) to head (c6c6c3b).
Report is 4 commits behind head on dev-2.x.

@@            Coverage Diff             @@
##             dev-2.x    #6295   +/-   ##
==========================================
  Coverage      69.78%   69.79%           
- Complexity     17781    17797   +16     
==========================================
  Files           2017     2019    +2     
  Lines          76040    76126   +86     
  Branches        7781     7786    +5     
==========================================
+ Hits           53067    53130   +63     
- Misses         20269    20289   +20     
- Partials        2704     2707    +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

What should the debug UI be named? In the UI it is called "OTP Debug Client" and here it is called "Debug UI" - We should settle on one name. The name "OTP Debug Client" is taking up too much space. So I suggested to shorten it to just "OTP Debug" - In the UI repeating "UI" or "client" is redundant.

So, maybe use "OTP Debug UI" in doc, "OTP Debug" as title in UI and "debug-ui-config.json" ?

I'm wondering if this is a little misleading? The debug-ui-config.json doesn't seem to directly configure the debug UI does it? I mean the debug UI code doesn't read the config file. Rather, the config file is read by the OTP application, and it configures some behavior related to the map style endpoint.

I guess my question is, do we want to use this config file also to configure other aspects of the debug UI or just the map styles?

We are planning to expand its role to cover other aspects of the debug UI.

We are planning to expand its role to cover other aspects of the debug UI.

I see, then we are looking at a way to serve this config file directly to the debug UI at runtime, since it then obviously can't be compiled into the static assets. Will it be available via a public endpoint in OTP?

I see, then we are looking at a way to serve this config file directly to the debug UI at runtime, since it then obviously can't be compiled into the static assets. Will it be available via a public endpoint in OTP?

There are no concrete plans yet but I also imagine an endpoint from which the debug UI gets the configuration values at runtime.

I'm ok with this change. My only two cents is that since we are introducing the concept configuration for the debug ui, it seems strange that we don't have a mechanism for the debug ui to fetch it. I suppose it can wait for some actual use case for that.

We thought about using router-config.json for this particular case, but a Gitter poll showed that almost everyone preferred a separate file for it.