Field being overridden when using Aliases and Directives

[tsinghammer]

We have an issue when trying to use a GraphQL query that contains a field twice, once the field as in the schema and the second time used fwith a directive to be asinged to an alias.

The fragment of the query looks like the following: fragment evAccountsTransactionsFilters on EvAccount { availableProducts { contractId productId productName: productId @translate } }

The @translate directive returns a translated version of the productId. The result from the server is this: availableProducts: [{contractId: "0010000000", productId: "SLPUP", productName: "Swiss Life FlexSave Uno"},{contractId: "0010000001", productId: "SLHUP", productName: "Swiss Life Champion Uno"},{contractId: null, productId: null, productName: null}]

So we do get it back from the server as expected. The data object in the <QueryRenderer> contains both fields but with the same value:

availableProducts: [{contractId: "0010000000", productId: "Swiss Life FlexSave Uno", productName: "Swiss Life FlexSave Uno"},{contractId: "0010000001", productId: "Swiss Life Champion Uno", productName: "Swiss Life Champion Uno"},{contractId: null, productId: null, productName: null}]

If I place the alias line before the line with the field itself in the query it is the other way round. Then both properties of the data object contain just the product code but not the translation.

Also, when debugging with the Relay DevTools, the store contains only the field productId where we would have expected the alias productName to be there, too.

[sibelius]

related to https://github.com/facebook/relay/issues/2736?

can you share more infor about this directive?

[artola]

related to #2736?

can you share more infor about this directive?

It is same issue, just #2736 is a simplified abstraction of #2737 real implementation

[josephsavona]

Relay creates a storage key for each field based on the schema field name and arguments/values used to fetch the field. Notably this ignores aliases, since aliases don't change the conceptual identity of a field, only the key by which it is presented in the results. Right now we don't take directives into account when computing the storage key, which explains the behavior you're seeing.

This is definitely an enhancement we could consider, though we'd want to implement it carefully to not incur any additional overhead in the common case of fields not using any directives.

[sibelius]

can we have the same strategy of 3D namespaces https://github.com/facebook/relay/commit/408057dc6ab287e3bc512f1f53c52c9c4902b30d?

[josephsavona]

can we have the same strategy of 3D namespaces

Kind of. Directives can accept (possibly variable) arguments and be used in all kinds of places (imagine a directive on a field containing a 3D resource, or a connection field). We'd probably have to add a new IR/concrete node kind and handle it appropriately throughout the compiler and runtime (so field @directive would transform into something like Directive{name: 'directive', args: [], selections: [ScalarField{name: 'field', ...}]}, and we'd synthesize a client record in the store for the directive (like w connections) in order to namespace the results of the fields under it correctly.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.