fix(jsonview): preserve literal keys throughout the interactive explorer - #121
Open
sylvesterkaczmarek wants to merge 1 commit into
Open
Conversation
Signed-off-by: Sylvester Kaczmarek <16242628+sylvesterkaczmarek@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make every interactive JSON-explorer object lookup use literal JSON member names instead of interpreting those names as GJSON path expressions.
This complements #86, which addresses the same class of bug in the static pretty renderer. The interactive explorer has its own independent lookup paths and remains affected without this change.
Related to #81.
Problem
The explorer enumerates real object member names with
@keys, but several rendering paths then feed those names back intogjson.Result.Get.Getparses its argument as a GJSON path, so a literal key such asa.bcan resolve the nested patha -> binstead of the top-level member named exactlya.b.For example:
{ "a.b": "literal-value", "a": {"b": "nested-value"} }can show
nested-valueunder thea.bkey even though the underlying JSON storesliteral-valuethere.The bug exists in four interactive paths:
Fixing only one of these leaves the same incorrect value substitution elsewhere in the explorer.
Fix
Once keys have been enumerated, materialize each object's literal map with
Result.Map()and index it directly by the key string. No GJSON path parsing is used for an already-known object member name.The change covers all four interactive paths above while leaving genuine navigation-path construction and user transformations unchanged.
Regression coverage
Added focused tests proving literal dotted keys remain distinct from nested paths in:
The fixtures deliberately contain both
"a.b"and nested{"a":{"b":...}}values so a path-based lookup deterministically returns the wrong value before the fix.Validation
The branch is based directly on current upstream
main(a7719136b8ed401b0c51a05553a5e4f720150307) and contains one DCO-signed commit. The production change is 9 additions / 4 deletions in handwritteninternal/jsonview/explorer.go, plus focused regression coverage. Full repository test execution is left to CI.Risk
Low. The explorer already has the literal member names. This change only stops reinterpreting those names as query expressions. Simple keys retain the same values, while keys containing GJSON path syntax now correctly refer to their own object members.