[normalize feature req] validation and safety utils about ferry HOT 6 CLOSED

I think this would be a great addition.

Would validateResponseStructure just return a bool? Or would it give some hints as to where the mismatched data is?

If a bool is sufficient, we could integrate validation into normalizeNode and denormalizeNode by default. Then we wouldn't need a separate validation method. We could just wrap writeQuery and readQuery in a try / catch and catch validation exceptions.

from ferry.

Just throwing an exception is sufficient for now – eventually surfacing mismatched paths could be a goal but we can add that to the exception details later as well

from ferry.

After thinking about this further, without having access to the schema, we'd really only be able to validate whether the data should be a Map (i.e. the node has a SelectionSet) or a scalar (i.e. the node doesn't have a SelectionSet), and I'm not sure how useful this would be.

So we could either:

1. include the schema as an optional parameter to the normalize functions, and if one is provided, perform a more thorough validation
2. implement validation as a separate function

How do you envision this being used? Would it be called directly by the user? Or are you incorporating validation into the graphql client automatically?

from ferry.

@smkhalsa we can tell from the document which fields the Map should have right? Because denormalize has to select the fields. That's mainly what I'm after, is just to validate that the structure is valid given the operation document.

This came up because for whatever reason a user's result.data was unexpectedly null and they had no idea why. So like, if a server responds to { foo, bar } with { foo: 1 }, denormalizeOperation(document, data) will return null

from ferry.

@micimize ah, ok.

The way that the denormalize functions work is that if a Map doesn't contain a key for a given FieldNode in the document (e.g. "bar" in your example above), the denormalizeNode function throws a PartialDataException. If returnPartialData is set to true, the exception is caught and ignored and the partial data is returned. If returnPartialData is set to false, the exception is caught and null is returned for the entire operation.

By default returnPartialData is set to false since:

1. non-nullable fields could potentially return null data
2. we may want to fetch from the network if all the data is not available for the operation (e.g. FetchPolicy.CacheFirst)

It sounds like in the case you describe above, if they want to receive partial data, they should be able to just set returnPartialData to true.

from ferry.

closed by #104

from ferry.