-
Notifications
You must be signed in to change notification settings - Fork 484
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
Don't rely on json-markup for non-json strings #587
Don't rely on json-markup for non-json strings #587
Conversation
8ba12a1
to
1f54d3a
Compare
Thanks for the PR. Please make sure the CI is green and all commits are signed. |
Signed-off-by: Simeon Manolov <[email protected]>
1f54d3a
to
abd1383
Compare
Signed-off-by: Simeon Manolov <[email protected]>
abd1383
to
6c76e93
Compare
Codecov Report
@@ Coverage Diff @@
## master #587 +/- ##
==========================================
- Coverage 93.55% 93.52% -0.03%
==========================================
Files 217 217
Lines 5289 5296 +7
Branches 1360 1362 +2
==========================================
+ Hits 4948 4953 +5
- Misses 300 302 +2
Partials 41 41
Continue to review full report at Codecov.
|
// if the value is a string representing actual json object or array, then use json-markup | ||
if (typeof value === 'string' && jsonObjectOrArrayStartRegex.test(value)) { | ||
if (typeof value === 'string') { |
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 does this logic need to change if the goal is to only remove the quotes? Attempting to parse any value as JSON led to bugs previously, where, for example, a string that looks like a number would get converted to number and change representation / precision.
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.
but it has not changed - see a few lines below.
Basically, the boolean &&
has been split into two separate conditionals, due to the need to explicitly handle non-json strings.
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.
ok, thanks. Could you please add unit tests that cover the new conditions? There are only two lines that are not covered: https://codecov.io/gh/jaegertracing/jaeger-ui/compare/3335512110c60ace5b089e1b61d187a6d6ec4000...6c76e930f59843f41817effbf3d57c3f3a999367/diff
Signed-off-by: Simeon Manolov <[email protected]>
801a528
to
de51eb6
Compare
Signed-off-by: Simeon Manolov <[email protected]>
1dcd55a
to
70cb812
Compare
Signed-off-by: Simeon Manolov <[email protected]>
@@ -47,8 +47,8 @@ describe('<KeyValuesTable>', () => { | |||
|
|||
const data = [ | |||
{ key: 'span.kind', value: 'client' }, | |||
{ key: 'omg', value: 'mos-def' }, | |||
{ key: 'numericString', value: '12345678901234567890' }, |
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.
please keep this, it's a real use case that cased problems in the past.
@@ -138,7 +138,7 @@ describe('<KeyValuesTable>', () => { | |||
expect(el.length).toBe(data.length); | |||
el.forEach((valueDiv, i) => { | |||
if (data[i].key !== 'jsonkey') { | |||
expect(valueDiv.html()).toMatch(`"${data[i].value}"`); | |||
expect(valueDiv.html()).toMatch(data[i].value.toString()); |
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.
Could we change the data table to contain the exact expectation instead of relying on toString()?
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 assume you are well aware that the string interpolation was basically doing the same thing.
I did try to make this test more meaningful by comparing against the actual text instead of matching against part of the DOM, but it did not work:
// ----------- this works
valueDiv.html()
// => "<div class="ub-inline-block"><div class="json-markup"><span class="json-markup-string">some text</span></div></div>"
valueDiv.text()
// => "some text"
// ----------- this not
valueDiv.html()
// => "<div class="ub-inline-block"><div><div class="json-markup"><span class="json-markup-number">some text</span></div></div></div>"
valueDiv.text()
// => ""
I know it is somehow related to the shallow representation of the DOM inside this test, but I am really not familiar with react and its test frameworks, so I am at a dead end.
If you can help me get "some text"
in the second example, I would implement the test change.
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.
sorry, maybe I didn't explain clearly. The test is data driven from the data
table. I suggest adding the expected values to that table, e.g. { key: 'numeric', value: 123456789, expected: "123456789" }
and comparing with those, instead of value.toString()
(which is not as obvious in terms of what it would produce).
Signed-off-by: Simeon Manolov <[email protected]>
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.
thanks! 👏
{ key: 'span.kind', value: 'client', expected: 'client' }, | ||
{ key: 'omg', value: 'mos-def', expected: 'mos-def' }, | ||
{ key: 'numericString', value: '12345678901234567890', expected: '12345678901234567890' }, | ||
{ key: 'numeric', value: 123456789, expected: '123456789' }, | ||
{ key: 'jsonkey', value: JSON.stringify({ hello: 'world' }) }, |
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.
sorry, how does this one pass if it doesn't have expected
field?
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.
Line 141 in 52e64dd
if (data[i].key !== 'jsonkey') { |
* don't rely on json-markup for non-json strings Signed-off-by: Simeon Manolov <[email protected]> * prettier Signed-off-by: Simeon Manolov <[email protected]> * fix quotes around non-json strings; test coverage Signed-off-by: Simeon Manolov <[email protected]> * lint Signed-off-by: Simeon Manolov <[email protected]> * prettier Signed-off-by: Simeon Manolov <[email protected]> * don't use toString in tests Signed-off-by: Simeon Manolov <[email protected]> Signed-off-by: vvvprabhakar <[email protected]>
Which problem is this PR solving?
Resolves #571
The presence of those quotes around strings is not only unnecessary (the value type is inferred from the text color), but also confusing (when the value itself contains quotes)
Short description of the changes
Added a separate function in case the value is a non-json string.
Before:
After: