Another migration question (sorry 😅) Before we used to construct objects like this, for a query which looked like this where the return type of

status

is

ContractStatus!

which is a union with the three things you saw in the query among others. This worked fine somehow, since the __typename in the constructor put

val __typename: String = "ContractStatus"

and parsing it was no problem. In 3.x, we do not get that for free, and I need to go and put the correct __typename to each and every one of those constructors, and I am trying to avoid this if possible. I’ve put

__typename = ""

everywhere to make it compile, and it works for most cases, but not for one like here where even the test builder can’t automatically populate the __typename and I need to specify it myself, like here. So now due to this change, I would need to either adopt the testBuilders which handle this for me by forcing me to chose the typename when I need to, and even give me a comment above it with the possible correct options in the generated code (Nice work there, super convenient). Or I need to just go and hunt all the places where this problem happens and manually put in the correct __typename in all these places. Am I missing something in this migration story? I understand that the way we construct the Data objects in our tests might be a bit unorthodox, hence an easy solution may not exist, so just asking here for ideas 🤗

The unfortunate reality is that the default

typename

was wrong in a lot of cases

Hmm it was wrong, but it somehow did manage to parse it and our tests did at least do what they had to do I think. Maybe I’m wrong though, not sure. What was it that would go wrong if the typename was wrong? I tried looking in the design doc for typenames in 3.x as well, but I don’t think any of these options would help my use case anyway right, since I simply need to provide the typename for these cases.

What was it that would go wrong if the typename was wrong?

Most likely nothing, depends what your tests do but if you're not reading

__typename

then you should be fine. I guess stuff could go wrong if you start storing these data structures in the cache or so.

Yeah, we were not asking the __typename itself, and the tests generally do not test the cache. Alright I think that this is one of those debts we have to pay. We took advantage of the rules being relaxed and used the wrong __typenames and with 3.x we’re not allowed to do that. So it’s a good step forward, we just need to keep up 😅 And no unfortunately

"unused"

does not work, as the tests take the data object, turn it into json, and then give it to the MockWebServer which is passed to the ApolloClient so the normal chain of fetching the request and parsing it back into objects need to work, and this is exactly what is failing if the typenames are not setup like this for these cases. This test fails particularly (made it to test what all of our UI tests are doing) with

asActiveStatus

being null if I do not explicitly set the typenames in lines : 67, 69, 75, 77 with those strings (or the other permitted alternatives) The parser doesn’t recognize it the way it comes from the json:

{
  "data": {
    "contracts": [
      {
        "__typename": "",
        "status": {
          "__typename": "",
          "upcomingAgreementChange": {
            "__typename": "",
            "newAgreement": {
              "__typename": "",
              "activeFrom": "2021-04-11"
            }
          }
        },
        "upcomingAgreementDetailsTable": {
          "__typename": "",
          "title": "Details",
          "sections": [
            {
              "title": "Details",
              "rows": [
                {
                  "title": "Address",
                  "subtitle": "Subtitle",
                  "value": "Testgatan 123"
                }
              ]
            }
          ]
        }
      }
    ]
  }
}

I see. Sorry I don't have a better answer right now. @bod might be a good Psi exercise to make a script that popuplates

__typename

automatically ? 🙂

Thank you, you’ve helped me even if there’s no “easy” solution, I know how to go forward with this with more confidence!