[Bug?]: `mockGraphQLQuery` not working correctly in Storybook when fragments are involved in a Cell

[keeganthomp]

What's not working?

When fragments are used in a cell, the object of the Success "sub component" is always an empty object. However, I can see the mock request 200 and the correct data from the mock in the network panel when inspecting the page.

See illustration below.

Below is a TestCell.js which utilizes fragments. We will call this one "Fragment Query":

fragment TestFragment on Result {
    id
    status
}

...

query testQuery($id: String!) {
    result(id: $id) {
      ...TestFragment
    }
    ${TestFragment}
}

Below is a TestCell.js which does NOT utilize fragments. We will call this one "No Fragment Query":

query testQuery($id: String!) {
    result(id: $id) {
      id
      status
   }
}

Each are in the top level of the TestCell.js succeeded by a Success component:

...

const Success = ({ result }: CellSuccessProps) => {
    console.log(result)
    return  <p>{result.status}</p>
}

We have a story that mocks the testQuery query:

import TestQueryCell from './TestQueryCell'

export const generated = () => {
  mockGraphQLQuery('testQuery', () => {
    return {
      result: {
        id: '1',
        status: 'active'
      },
    }
  })
  return <TestQueryCell />
}

If we utilize the "Fragment Query" testQuery, the log of the result above will be {} and throw an errors saying "cannot read status of undefined".

If we utilize the "No Fragment Query" testQuery, the log of the result above will be { id: '1', status: 'active' } and renders "active".

However, the mock network request in both cases will show the correct payload in the network panel:

{
  result: {
    id: '1',
    status: 'active'
   }
}   

How do we reproduce the bug?

No response

What's your environment? (If it applies)

System:
    OS: macOS 13.3
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 19.8.1 - /private/var/folders/j1/4l9fggwn6gl1sjt69670m5yh0000gn/T/xfs-82743d28/node
    Yarn: 3.3.1 - /private/var/folders/j1/4l9fggwn6gl1sjt69670m5yh0000gn/T/xfs-82743d28/yarn
  Databases:
    SQLite: 3.39.5 - /usr/bin/sqlite3
  Browsers:
    Chrome: 112.0.5615.49
    Edge: 111.0.1661.54
    Firefox: 111.0.1
    Safari: 16.4
  npmPackages:
    @redwoodjs/auth-clerk-setup: 4.4.1 => 4.4.1
    @redwoodjs/core: 4.4.1 => 4.4.1

Are you interested in working on this?

• [ ] I'm interested in working on this

[thedavidprice]

Thanks @keeganthomp This is definitely not a use-case we originally considered.

@virtuoushub any thoughts about this one?

[virtuoushub]

@virtuoushub any thoughts about this one?

not at this time.

@keeganthomp is there a reproduction repo I am able to take a look at?

[keeganthomp]

@virtuoushub not right this second. I first came across this in my companies repo, which is private.

I can whip up a very basic redwood boilerplate app demonstrating this issue though. Would that be helpful?

[keeganthomp]

@virtuoushub @thedavidprice

Here is a simple repo illustrating the issue. If you have any issues with it, let me know.

https://github.com/keeganthomp/redwood-storybook-issue

You should see the below when running yarn rw storybook in that repo

[virtuoushub]

@virtuoushub @thedavidprice

Here is a simple repo illustrating the issue. If you have any issues with it, let me know.

https://github.com/keeganthomp/redwood-storybook-issue

You should see the below when running yarn rw storybook in that repo

awesome thanks! Will take a look.

[virtuoushub]

Was able to reproduce the observed screenshots using the repo, thanks @keeganthomp !

One question I have is:

If we utilize the "Fragment Query" testQuery, the log of the result above will be {} and throw an errors saying "cannot read status of undefined".

I was not able to see this error using the repo, how were you seeing this error?

---

I started a PR to see if I can figure out what is going on #8072 , has not yielded anything yet; so any extra error information is much appreciated.

[keeganthomp]

@virtuoushub apologies. That comment was in reference to our real repo. That error has nothing to do here. Apologies for the confusion.

This simply illustrates the core issue, that is, data is not passed through to the success component when fragments are involved using the mockGraphQLQuery util.

[virtuoushub]

Hi again @keeganthomp, took some time to look at this some more with @jtoar and we have a temporary work around while we continue look into fixing what is going on.

Please check it out: https://github.com/keeganthomp/redwood-storybook-issue/pull/1/files

---

Unfortunately, it looks like the underlying issue is a bit tricky. Will report back here once we know more.

[virtuoushub]

@keeganthomp so the tl;dr is that for mocked data when Fragments are used, __typename is required.

---

The gist of the root cause is that due to our use of Apollo Client, and it's implementation needing to specify data that contains a __typename; Apollo Client will never be able to connect the dots that this data contains an entity of a certain type - and you will not be able to read it with a Fragment, since those always read from entities of a specific type.

For outgoing requests/responses, Apollo usually adds it automatically; but with mocked data, that's out of it's reach and we need to manually add it for the time being.

I am working w/ @jtoar to see if Redwood can handle this for us under the hood, in the meantime we will work on updating the documentation to reflect this behavior. Thanks for reporting/providing a reproduction repo!

[keeganthomp]

@virtuoushub thanks so much for the response! Apologies for missing your previous comment.

I greatly appreciate you looking into this. u rule :)

[virtuoushub]

I am working w/ @jtoar to see if Redwood can handle this for us under the hood, in the meantime we will work on updating the documentation to reflect this behavior. Thanks for reporting/providing a reproduction repo!

I don't think a fix for this has been implemented, my suggestion for the easiest solution is to update the documentation to reflect the current behavior _(Apollo Client needing to specify data that contains a __typename which is especially relevant to mock data [i.e. fixtures], Fragments, and in turn Storybook)_.