Should we remove `isFallible` from reader ast?

[PatrykWalach]

Just an idea, I don't know if it's any better - reading might be slower, but the artifacts should be smaller.

isFallible was added in normalization ast and reader ast #945 it only indicates how the value is stored.

Instead of generating fields on normalization ast nodes we could generate a map at the root of the ast

const normalizationAst: NormalizationAst = {
  kind: "NormalizationAst",
  fallibleFields: {
    Pet: ["name"],
  },
  selections: /* ... */
}

Then at normalization time we merge this into the same kind of map attached to the store and during reading we can lookup the map. We probably have to serialize this map during ssr.

[rbalicki2]

I think the concept of fallibility is a compiler only concept. I think of the current state as a transition to what we actually want to achieve.

In my opinion, the ideal state is that there is a transform before we normalize, which converts fallible fields to { kind: Ok, value }. Then, the normalization AST can not know about fallibility at all.

However, another reasonable way to implement this, and the actual one we I think we should do, is to have in-line transform functions inside of the normalization AST. (my one concern is that this doesn't seem to work for global errors and such so, maybe we still need the global pre-normalization transform.) these functions can convert fallible fields two unions.

I don't think readers need to know about fallibility. What we need is a function that maps the union to a value. Client fields already do that! So, in my opinion, we should generate client fields for each nullable field. These client fields can throw for semantically non null, and return a nullable field otherwise.

It would be great in the long run to have a single client field for unwrapping semantically null fields and one for semantically non null fields, but duplication seems fine in the short term