-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Blocked] Query-Service config and runtime configuration of URL path-prefix #151
Conversation
Signed-off-by: Joe Farro <[email protected]>
Signed-off-by: Joe Farro <[email protected]>
Signed-off-by: Joe Farro <[email protected]>
Signed-off-by: Joe Farro <[email protected]>
wouldn't they still have a fixed prefix |
public/index.html
Outdated
const JAEGER_CONFIG = DEFAULT_CONFIG; | ||
return JAEGER_CONFIG; | ||
const DEFAULT_UI_CONFIG = null; | ||
const JAEGER_UI_CONFIG = DEFAULT_UI_CONFIG; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need DEFAULT_ constants? When I originally proposed them I thought they would have some concrete values, and it was easier to search&replace the string JAEGER_UI_CONFIG = DEFAULT_UI_CONFIG
than to replace the JS expression on the right hand side. But these are always null anyway, we might as well have JAEGER_UI_CONFIG = null
, it's just as easy to search&replace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do that.
I think tweaking the name a bit to imply it might be over-written has some value, though:
// use `null` as a fallback value if the query-service does not embed a value
const __INJECTED_UI_CONFIG__ = null;
const JAEGER_UI_CONFIG = __INJECTED_UI_CONFIG__;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for __INJECTED_UI_CONFIG__
. I don't think you need the second const, you can simply return __INJECTED_UI_CONFIG__;
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great. Done.
@@ -116,7 +116,7 @@ export default class SearchTracePage extends Component { | |||
!hasTraceResults && ( | |||
<div className="ui middle aligned center aligned grid" style={{ marginTop: 100 }}> | |||
<div className="column"> | |||
<img className="js-test-logo" alt="presentation" src={JaegerLogo} width="400" /> | |||
<img className="js-test-logo" alt="presentation" src={prefixUrl(JaegerLogo)} width="400" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was it using relative url before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it uses an absolute path.
The image is imported in JS:
import JaegerLogo from '../../img/jaeger-logo.svg'; |
That does two things:
- Causes the asset to be stored in
/static/media/
with a filename derived from the file's hash - Stores the eventual absolute path of the media asset in the variable
JaegerLogo
The absolute path is then used in the JSX as you excerpted.
The prefixUrl(...)
adds the path-prefix, if it is configured.
It's not that much different, and we can go down that road. It would spare any impact to the initial page-load time and remove the need for react-app-rewired. The expression(s) in u.src=t.p+"static/js/"+({}[e]||e)+"."+{0:"03cf6b4e"}[e]+".chunk.js"; The filesize of |
Signed-off-by: Joe Farro <[email protected]>
config-overrides.js
Outdated
// prevent code-splitting to allow the URL path-prefix for the site to be | ||
// configurable at runtime | ||
// https://github.com/jaegertracing/jaeger-ui/issues/42 | ||
new webpack.optimize.LimitChunkCountPlugin({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so which way are we going, global search&replace of the path in the query service or using this plugin to not split the js files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yurishkuro Still up for debate.
The main considerations:
- Primarily - The exact form the loading of JS chunks takes (which is the site of the search/replace) has an unknown level of risk of changing
- The search/replace in the JS files is not as "clean" as the others
- The main.js filesize is ~2M, on disk (not sure to what extent that is much of a consideration)
Note: every *.js file, not just main.NNNN.js, must be checked for the static/js
path and prefixed if found
So, my main concern is around maintainability.
The above inconveniences allow us to avert a likely hit on initial page-load time, possibly a ~5% increase.
The ideal scenario, IMO, is to do the global replace and if maintaining it is a PITA then revert and go with the plugin approach to not split the files. Not sure how feasible that approach is on the query-service side.
Would that work for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I would suggest trying global replace first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. This PR needs some rework, then.
Closing, will re-open when I've reverted the chunkless changes. |
Signed-off-by: Joe Farro <[email protected]>
Signed-off-by: Joe Farro <[email protected]>
Reopening this PR. Main change necessary, from the previous state, was to revert the removal of the chunk generation. It's worth noting, this PR requires several changes to the query-service, as noted in the PR description. |
Codecov Report
@@ Coverage Diff @@
## master #151 +/- ##
=========================================
+ Coverage 90.77% 90.8% +0.02%
=========================================
Files 93 94 +1
Lines 1930 1935 +5
Branches 383 382 -1
=========================================
+ Hits 1752 1757 +5
Misses 155 155
Partials 23 23
Continue to review full report at Codecov.
|
Looking back at this, create react app documents a section on this. Looks like we are doing this already +1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ys can you mark this PR with "Request changes" so merging it will be blocked until the necessary changes in the query-service are ready?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like this one bit, scrap it all
Can you please stop mentioning me all the time here! I think it is about someone else |
@ys Apologies! I'll block you so it doesn't happen again! |
@yurishkuro Doesn't look like the work needed in the query-service for this PR is going to be on the docket anytime soon... Think it makes sense to close this PR? |
This PR is waiting on work from the query-service, which is currently not scheduled. So, I'm closing and will mark the ticket as blocked. |
Do we have a ticket in the main repo w/ description of what needs to be done? We can tag it "help wanted". |
@yurishkuro I'll create an issue in the main repo once I create the PR for the |
This PR is no longer relevant.
Refer to #198.
Fix #42.
Adds config data from the query service that is separate from the UI config, dubbed
querySvcConfig
.Presently, this contains a single property,
pathPrefix
, which causes the UI to handle being served from a URL prefix, at runtime.When set, the
pathPrefix
should be formatted as/xyz
.Query-service changes
Changes in the query-service this PR relies on:
Config injection
DEFAULT_CONFIG
to__INJECTED_UI_CONFIG__
return __INJECTED_UI_CONFIG__;
replacement__INJECTED_QS_CONFIG__
index.html
in a manner similar to the UI config, e.g. as JSON:{"pathPrefix":"/xyz"}
Static assets that need URL rewrites in their content
In order for the URL path prefix to work, the all URLs need to have the prefix pre-pended. This essentially amounts to the reference to the favicon and references to static assets (including references in static assets).