fix(jsonview): preserve literal object keys in pretty output and explorer - #143
fix(jsonview): preserve literal object keys in pretty output and explorer#143Ultron09 wants to merge 1 commit into
Conversation
…orer Resolve literal JSON object keys directly rather than interpreting them as GJSON path expressions across static pretty formatting, interactive table views, and object preview rendering. Fixes openai#81
sylvesterkaczmarek
left a comment
sylvesterkaczmarek
left a comment
There was a problem hiding this comment.
Checked the affected renderer/explorer paths. @keys still supplies object/column order, while Map() is now only used for exact literal lookup, so dotted or metacharacter keys can't be reinterpreted as GJSON paths. columnKeys is also preserved for paged rows. The static, object-table and array-of-object regressions cover the main paths. Looks consistent.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Security review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
3 participants
Summary
Preserve literal object keys across pretty formatting and the interactive JSON explorer instead of resolving member names containing dots or metacharacters as GJSON query paths.
Fixes #81.
Problem & Root Cause
The JSON renderer and explorer enumerate literal member names with
@keys/gjson.Result.Get("@keys"), but subsequently fetched each value throughresult.Get(key.Str),data.Get(key.Str), oritem.Get(key).Because GJSON interprets string arguments to
.Get()as path expressions (such as evaluating"a.b"as a traversal into nested objecta -> b), keys with dots or other GJSON path syntax either:Fix
Materialize the object map once with
result.Map()and look up values by exact literal key:internal/jsonview/staticdisplay.go:formatJSONObjectinternal/jsonview/explorer.go:newObjectTableView,newArrayOfObjectsTableView,TableView.loadMoreData, andformatObjectRegression Coverage
Added comprehensive regression tests in
internal/jsonview/literal_keys_test.go:TestStaticDisplayUsesLiteralObjectKeys: confirms static pretty formatting preserves top-level dotted keys and nested paths concurrently.TestExploreTableUsesLiteralObjectKeys: confirms object table view and array-of-objects table view display the literal key's value.TestExploreFormatObjectUsesLiteralObjectKeys: confirms object previews format literal keys correctly.Validation Commands & Results
go test -v ./internal/jsonview/...(PASS)go test ./pkg/cmd -run TestFormatJSON(PASS)go vet ./internal/... ./pkg/...(PASS, clean)go mod verify(PASS, all modules verified)git diff --check(PASS, clean)