feat (api): support to custom types

[erickriva]

Description of changes

Added support for custom types in GraphQL API.

Issue #, if available

Refer to aws-amplify/amplify-category-api#2096, but I managed to work modifying this lib.

Description of how you validated changes

Installing locally in a real app project.

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[erickriva]

@svidgen @iartemiev I hope you can help me with it.
Apparently, it is needed a change in types from @aws-amplify/data-schema-types for custom types to work as a fully experience. Can I contribute to it or this is a private package?

Edit: as far i can see, this PR is fully working and ready to merge. I just don't mark it as 'ready for review' because I don't know if makes sense to merge it without TS is fully functional.

[iartemiev]

@erickriva thanks for opening another PR! data-schema-types is indeed in a private repo. We will be migrating the code into https://github.com/aws-amplify/amplify-category-api/ in the near future.

In the meantime we'll work on adding Custom Type support to the custom selection set types. We'll release a new version of that package once that's ready. Most of the team is out on vacation right now, so realistically we should be able to get it out towards the end of next week. I'll let leave a comment here as soon as the new version of the types package has been published.

[iartemiev]

@erickriva btw the type issues appears to be limited to nullable custom type fields specifically.

E.g. if you were to change your field definition to before: a.ref("PregnancyBefore").required()
You can use a selection set like ['before.*', 'before.tryingSince'] without type errors.

We'll work on supporting nullable custom type fields with custom selection set.

[iartemiev]

@erickriva we just published an updated version of data-schema-types@0.6.11

This version includes the correct paths for custom types on nullable fields in the generated custom selection set type, e.g. [ "id", "before.tryingSince" ] should no longer surface a TS error.

To get access to these changes please update the 2 data-schema dependencies in api-graphql/package.json:

"devDependencies": {
  "@aws-amplify/data-schema": "^0.12.13",

and

"dependencies": {
  "@aws-amplify/data-schema-types": "^0.6.11",

[erickriva]

@iartemiev Thanks for the answer. Sadly, I have no access to my computer at the moment to test this update, but as soon as I get access I'll be checking if it works well.

[erickriva]

@iartemiev Nice! It's working good. Setting it as Ready for review.

[erickriva]

@iartemiev I may have found a blocker.

Checking AppSync for schema, props related to custom types are not generated in GraphQL types Model{MODEL_NAME}ConditionInput and Model{MODEL_NAME}FilterInput.

Don't know if this is a bug or a feature not implemented yet. Can you clarify it?

[iartemiev]

@erickriva I'm sorry, I missed your updates on this PR. I'll get it reviewed ASAP. Could you please resolve the conflicts when you get a chance?

[iartemiev]

@iartemiev I may have found a blocker.

Checking AppSync for schema, props related to custom types are not generated in GraphQL types Model{MODEL_NAME}ConditionInput and Model{MODEL_NAME}FilterInput.

Don't know if this is a bug or a feature not implemented yet. Can you clarify it?

I believe this is expected behavior at the moment. What are the use cases you have in mind that are blocked by this?

[erickriva]

Think of an app which has a 'diary' annotation, which multiple people can edit simultaneously.
It shows only days of a week in a row (initially current week), with a check indicator if there is already an existing annotation.

What if 'Person A' adds an annotation for any day of past week?
'Person B' app would need to get all items in database (probably using a lot more of bandwidth) and re-render UI components because of new data, but past week is not even showing in screen.

Bandwidth and re-renders could be cut, improving user experience without much work (good for a simple app).

[iartemiev]

@erickriva couldn't you just use a model field for that value, which is already filterable? What's the benefit specifically for custom types?

[iartemiev]

Could you please bump the size limit here to 37.50 kB

[erickriva]

@erickriva couldn't you just use a model field for that value, which is already filterable? What's the benefit specifically for custom types?

Surely not the best example 🤔. I have created off the top of my head, trying to explain it. Maybe missing some details.
Well, I will check my specific use case later for possibility to use a model. If needed, I can open a new issue. Anyway, I believe this PR is not tied to it.

[iartemiev]

@erickriva - thank you so much for contributing to Amplify again! These changes have now been published to the latest aws-amplify@unstable version. They'll be included in the next stable release ETA <= 1 week.

[JJK801]

@erickriva 🙏 thank for your fix as it solves a problem on which i spent several hours today (inconsistent returns from observeQuery when using selectionSet)