createCell: Give cell results priority over cell props

[Tobbe]

This PR resolves #2962

It's not the solution we decided on, but it's the solution I want 😁

So, this is the setup

<JoinCell inviteCode={inviteCode} />

and a cell query like this

export const QUERY = gql`
  query JoinTeamQuery($inviteCode: String!) {
    inviteCode(code: $inviteCode) {
      code
      expiry
    }
  }
`

And finally a Success component like this

export const Success = ({ inviteCode }) => {
  return <pre>{JSON.stringify(inviteCode, null, 2)}</pre>
}

With my new implementation you'd see this:

{
  "__typename": "InviteCode",
  "code": "1NBVWN",
  "expiry": "2022-01-31T16:04:00.000Z"
}

With the old implementation all you'd get was this:

"1NBVWN"

And, finally, if you want to get at the actual props that have been over-ridden by the query result you can find them in variables:

export const Success = ({ inviteCode, variables }) => {
  return <pre>{JSON.stringify({ inviteCode, variables }, null, 2)}</pre>
}

{
  "inviteCode": {
    "__typename": "InviteCode",
    "code": "1NBVWN",
    "expiry": "2022-01-31T16:04:00.000Z"
  },
  "variables": {
    "inviteCode": "1NBVWN"
  }
}

[Tobbe]

The alternative, that was discussed, was to throw an error if the query result name clashes with a prop name.

I think this solution is more inline with what we do if a query param clashes with a path param (path param always takes precedence). I also think it fits with RW's opinionated nature of just deciding on how things should work, that's the right fit 99 times out of 100, and provide ways to work around it for the 1%.

[jtoar]

Looks good! commonProps becomes a little less useful/precise of an abstraction but I can't think of a better name right now

[Tobbe]

Yeah, I know. I considered getting rid of it and just spread everything where it's used. You want me to do that instead?

[jtoar]

Yeah that'd be better at this point I think

[Tobbe]

Yeah that'd be better at this point I think

Done!

[Tobbe]

Technically this is a breaking change. How vocal do we need to be about that?

[Tobbe]

Discussed this on a Core Team meeting today. We're good to go with this solution.

[thedavidprice]

@Tobbe I'll leave it to you and @jtoar to handle next steps (merge, docs, etc.) Just keep me posted otherwise.

[thedavidprice]

@Tobbe were any doc updates needed with this one? (just a nudge... no need to reply)

[Tobbe]

@thedavidprice I'm already talking to Dom about docs. We'll figure it out 🙂