Conversation
lodash `mapKeys` on an array returns a plain object keyed "0","1",…, so any response whose `data` is a top-level array was silently converted to an object by HttpClient's snake->camel pass. Collection.searchTitle() and Video.getThumbnails() threw `(res.data || []).map is not a function`, and Connection.getInvoices() returned an index-keyed object instead of the declared array. Map arrays element-wise before falling through to the object chain, matching the guard fromCamelToSnake already has. Object behaviour is unchanged.
fix: keep top-level arrays as arrays in fromSnakeToCamel
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.
Pull Request
Description:
Patch release 0.3.2. Fixes snake_case to camelCase conversion of API responses
whose payload is a top-level array, then bumps the version and writes the
changelog entry.
fromSnakeToCamel()ran its input through lodashmapKeys, which turns anarray into a plain object keyed
"0","1", and so on. Any response whosedatawas an array therefore reached callers as an index-keyed object ratherthan an array. Three methods were broken by this:
Collection.searchTitle()threw(res.data || []).map is not a functionVideo.getThumbnails()threw the sameConnection.getInvoices()resolved to an object instead of theunknown[]its signature declares
Arrays are now mapped element-wise before falling through to the object chain,
which is the guard
fromCamelToSnake()already had. Object conversion isuntouched, so nothing else in the response path changes behaviour.
Changes:
fromSnakeToCamel()keeps a top-level array an array (src/utils/index.ts)empty arrays, arrays of primitives, and the unchanged object path
(
test/regressions.spec.ts)package.jsonandpackage-lock.json.binaryConfig.versionstays at 0.3.1 on purpose, since it pins thecapture binary artifact and its checksums, not the package
CHANGELOG.mdentry for 0.3.2Related Issues:
None filed. Found while calling
searchTitle()against a live collection.Testing:
npm testpasses, 23 tests across 2 suites, including the 9 new cases intest/regressions.spec.tsnpm run buildruns clean throughtscandtsc-aliaspreviously received an index-keyed object and downstream code may have been
written around that shape:
Collection.searchTitle(),Video.getThumbnails(),Connection.getInvoices()Checklist: