Non string identifying argument values#895
Closed
josephsavona wants to merge 3 commits intofacebook:masterfrom
Closed
Non string identifying argument values#895josephsavona wants to merge 3 commits intofacebook:masterfrom
josephsavona wants to merge 3 commits intofacebook:masterfrom
Conversation
Member
Author
|
@facebook-github-bot import |
Contributor
|
Thanks for importing. If you are an FB employee go to Phabricator to review. |
This was referenced Mar 2, 2016
4 tasks
venepe
pushed a commit
to venepe/relay
that referenced
this pull request
Mar 7, 2016
Summary:Note: this is inspired by and partially based on iamchenxin's work in facebook#767 and facebook#844. Thanks for the head start! Relay currently assumes that identifying argument values are strings (numbers *sort* of work, but not really). This builds on facebook#894 (which added support to the plugin for parsing/printing literal InputObjects) by allowing identifying arguments to be basically anything - boolean, number, string, or array/object of the the same. Key changes include: - Change the `CallValue` type from mixed to an explicit list of the supported types - Change `forEachRootCallArg` to return both the literal JS value of the argument as well as a serialized key - Change all callers of `forEachRootCallArg` (and some places that manually inspected the identifying arg) to correctly choose between the identifying argument value (i.e. when constructing a query with it) or the identifying argument key (for use with `RelayRecordStore.{putDataID,getDataID}`). - Added tests that the writer correctly creates root records with numeric/object identifying argument values. Closes facebook#895 Reviewed By: yungsters Differential Revision: D3003201 Pulled By: josephsavona fb-gh-sync-id: 43ffbbd37e8d2bd8c0abe2cb792ad8959efb7a42 shipit-source-id: 43ffbbd37e8d2bd8c0abe2cb792ad8959efb7a42
Closed
This pull request was closed.
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
2 participants
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.
Note: this is inspired by and partially based on @iamchenxin's work in #767 and #844. Thanks for the head start!
Relay currently assumes that identifying argument values are strings (numbers sort of work, but not really). This builds on #894 (which added support to the plugin for parsing/printing literal InputObjects) by allowing identifying arguments to be basically anything - boolean, number, string, or array/object of the the same.
Key changes include:
CallValuetype from mixed to an explicit list of the supported typesforEachRootCallArgto return both the literal JS value of the argument as well as a serialized keyforEachRootCallArg(and some places that manually inspected the identifying arg) to correctly choose between the identifying argument value (i.e. when constructing a query with it) or the identifying argument key (for use withRelayRecordStore.{putDataID,getDataID}).