@steveluscher thoughts on this? The restriction on string arguments is largely arbitrary, how hard would it be to just allow any type?

Thanks for these contributions, @iamchenxin!

Instead of warning and documenting (#764) this behavior, how would you feel about fixing it? Here's what needs to happen:

Right now, we use the identifyingArgValue as a key in the rootCallMap and cachedRootCallMap of the RelayRecordStore. This is a map from identifyingArgValue to DataID. Because keys can only be strings, we enforce that every root call's identifyingArgValue is a string.

What you could do to fix this would be to modify getDataID and putDataID (link)to accept identifyingArgValues other than strings, then to stringify them if they are not already a string:

• If identifyingArgValue is already a string, use it as the key like normal
• If identifyingArgValue is an object, stringify it using stableStringify and use the result as the key

Are you up for that?

@steveluscher I am not familiar with Relay yet,and I am learning both Relay and English these days ,So when i make sure i can figure out the meaning of most Relay Store's functions, i should and would do this. Maybe one or two weeks later.
BTW: I thought the string restriction is deliberately designed before . When i first learn to use relay, i tried to pass Object and int as args to the top-level .But then the string restriction lead me to another design semantic .. keep the top-level fields of query as simple interfaces.

I am learning more about Relay, then i may not be confused with the relationship between each parts.

Someone just hit this restriction internally, where their identifying argument was an integer. Relay, as you've noticed above, turned it into a string. If you have time to open Relay up to objects, integer, and string identifying arguments, that would be a tremendous help, @iamchenxin!

@steveluscher Just back from Chinese new year today, i will try to fix it tomorrow .

Hi @iamchenxin ! I had the same problem when I tried to use an integer identifying argument. If you have the opportunity to look into this issue, it would help a lot! Let us know if you need help!

@vdurmont in the process of writing unit test , will pull the code before i go to sleep.
writing additional type for test in testschema.graphql now.

@vdurmont hi,i go to sleep. and update the uncompleted code to a new pull request. (you review them first, check if i got the right idea).
#844.
Im not familiar with flow and jest. so i use ?any temporarily (should be something like number|string|object).
number support should already worked.
Object support maybe need modify more files? but maybe im tired so i misunderstand some files,or i write wrong GraphQL type for test. will continue tomorrow.

@iamchenxin Thanks for starting the discussion about this! I've created two new PRs that build on these ideas in #894 and #895, so let's continue discussion there.