-
-
Notifications
You must be signed in to change notification settings - Fork 600
fix: Type regressions in ascending/descending fields #2919
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
Open
swittk
wants to merge
3
commits into
parse-community:alpha
Choose a base branch
from
swittk:fix-ascending-descending-types
base: alpha
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
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 you give more context about why this changed from
Array<string>tostring?Parse.Query.selectusually takes an array, but from the description I understand it also accepts a single string with comma separation. I think we should remove this type ambiguity and make select only accept an array of strings. If you agree we could pin the change for the next major release. We should then keep using the array type wherever possible because we'll have to revert to it.Uh oh!
There was an error while loading. Please reload this page.
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 for the late reply; there isn't really any need for this change (it could be just ['$score'] the same as before), but there's really no real behavioural difference underneath I think; internally it just calls Array.isArray(key) check before, but then it does the key.join() immediately after + does a split(',') afterwards, so internally it supports all 3 types I mentioned (single array of keys, keys as string args, keys as string with comma splitting), and even likely supports a mix-and-match of all 3 types as multiple args due to how it's implemented in the
addAscendingandaddDescendingcall sites.The typings I think what people are definitely using (at least in my team) are:
.addAscending('key1', 'key2')(the variadic arguments version).addAscending(['key1', 'key2'])(the array args version)I don't recall seeing the comma separated string thing documented, but it's definitely working and has been there a long time. I don't think we should remove this to be honest. I do have an idea for how to make the comma-separated typed multiple keys thing work strongly typed, but I was thinking of doing a separate PR for this since it seemed like a bit of TS magic. Just making keys typed the conventional way seemed straightforward.
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.
@mtrezza sorry for the ping; do you have any suggestions to what I should edit?
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.
@mtrezza, here are my suggestions on the two concerns raised:1. The
sortByTextScorechange (['$score']→'$score')This change is a net improvement — it removes the
as anytype cast that was only needed because'$score'wasn't previously a recognized key in theselectsignature. Now that'$score'is explicitly typed, passing it as a plain string is both correct and cleaner. No behavioural difference exists at runtime (the method internally callsArray.isArray(key)then pushes/joins accordingly). I'd keep this change as-is.2. Type inconsistency:
ascendingvsaddAscendingfor'$score'There is a subtle inconsistency in this PR worth addressing.
ascendingincludes'$score'in its type constraint, butaddAscendingdoes not — even thoughascendingdelegates toaddAscendinginternally:This means
query.ascending('$score')is valid TypeScript, butquery.addAscending('$score')is a type error, even though both work identically at runtime. The same gap exists fordescendingvsaddDescending. I'd suggest aligning all four methods to include'$score'in this PR.3. Broader API ambiguity (
stringvsstring[]vs variadic)Regarding mtrezza's suggestion to restrict
select(and the sort methods) to arrays-only in a future major release — that seems reasonable as a long-term goal. For now, documenting all supported call signatures in the JSDoc and leaving the enforcement for a major release would be the least disruptive path. If you'd like, I can open a follow-up issue to track this.🧠 Learnings used
Uh oh!
There was an error while loading. Please reload this page.
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.
Then we shouldn't use it, because we may remove it. If it's a long-standing feature, then we might do it with the major version release, even though it's undocumented, just to minimize the effects. But in general, we need to get out of this multi-type hell. It complicates code, adds complexity where it's not necessary. That means more bugs, more maintenance effort.
For code examples, I suggest to use the variant we'll keep, which is the Array version, otherwise we have more work when we remove the other types in the future.
Does this help?
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.