amplify-category-api icon indicating copy to clipboard operation
amplify-category-api copied to clipboard

All Models are nested deeper under "type"

Open ideen1 opened this issue 1 year ago β€’ 5 comments

Environment information

System:
  OS: macOS 13.6.6
  CPU: (10) arm64 Apple M1 Pro
  Memory: 196.94 MB / 16.00 GB
  Shell: /bin/zsh
Binaries:
  Node: 20.10.0 - /usr/local/bin/node
  Yarn: 1.22.22 - /usr/local/bin/yarn
  npm: 10.2.3 - /usr/local/bin/npm
  pnpm: undefined - undefined
NPM Packages:
  @aws-amplify/backend: 1.0.0
  @aws-amplify/backend-cli: 1.0.1
  aws-amplify: 6.2.0
  aws-cdk: Not Found
  aws-cdk-lib: 2.138.0
  typescript: 5.4.5
AWS environment variables:
  AWS_STS_REGIONAL_ENDPOINTS = regional
  AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
  AWS_SDK_LOAD_CONFIG = 1
No CDK environment variables

Description

After updating @aws-amplify/backend to 1.0.0, all of my model's data is now nested one level deeper under a field called type. For Example, before I could go client.models.list().data.id whereas now I must go client.models.list().data.type.id

Potential cause: It seems to be introduced by a version bump of data-schema in PR aws-amplify/amplify-backend#1399 A type field has been added to the InternalClientSchema type within data-schema.

ideen1 avatar May 07 '24 06:05 ideen1

HeyπŸ‘‹ thanks for raising this! I'm going to transfer this over to our API repository for better assistance πŸ™‚

ykethan avatar May 07 '24 13:05 ykethan

@ideen1 - can you confirm your package.json file? I can't seem to reproduce your issue

renebrandel avatar May 07 '24 14:05 renebrandel

I don't see the "type.id" being suggested: image

renebrandel avatar May 07 '24 14:05 renebrandel

Hey @renebrandel I have also reproduced this on a brand new app setup with: npm create amplify@latest

My package JSON contains the following relevant modules:

  "name": "bin",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@aws-amplify/backend": "^1.0.0",
    "@aws-amplify/backend-cli": "^1.0.1",
    "aws-cdk": "^2.140.0",
    "aws-cdk-lib": "^2.140.0",
    "constructs": "^10.3.0",
    "esbuild": "^0.21.1",
    "tsx": "^4.9.3",
    "typescript": "^5.4.5"
  },
  "dependencies": {
    "aws-amplify": "^6.3.0"
  }
}

Here is an image with the type of the default project Schema, also showing the issue: Screenshot 2024-05-07 at 11 30 53 PM

ideen1 avatar May 08 '24 05:05 ideen1

@renebrandel Okay I found something significant: Even the amplify-next-pages-template has this issue. See: Line #8 on https://github.com/aws-samples/amplify-next-pages-template/blob/main/pages/index.tsx

The Official Gen 2 docs do not reflect this change but, it seems as though the creator of the template also encountered the issue and adjusted for it. This template and the docs are inconsistent with each other. The issue does not seem to be consistent though because you are not seeing it.

A quick look at the PR mentioned in my original message shows that the data-schema module changed these lines potentially causing this issue:

type InternalClientSchema<Schema extends GenericModelSchema<any>, NonModelTypes extends NonModelTypesShape = ExtractNonModelTypes<Schema>, ResolvedSchema = ResolveSchema<Schema>, ResolvedFields extends Record<string, unknown> = Schema extends RDSModelSchema<any, any> ? ResolveStaticFieldProperties<Schema, NonModelTypes, object> : ResolveFieldProperties<Schema, NonModelTypes>, IdentifierMeta extends Record<string, any> = ModelIdentifier<SchemaTypes<Schema>>, SecondaryIndexes extends Record<string, any> = Schema extends RDSModelSchema<any, any> ? object : ModelSecondaryIndexes<SchemaTypes<Schema>>> = CustomOperationHandlerTypes<ResolveCustomOperations<Schema, ResolvedFields, NonModelTypes>['customOperations']> & {
    [K in keyof ResolvedFields]: {
        type: ResolvedFields[K];
    };
} & {
    [__modelMeta__]: IdentifierMeta & SecondaryIndexes & RelationalMetadata<ResolvedSchema, ResolvedFields, IdentifierMeta> & NonModelTypes & ResolveCustomOperations<Schema, ResolvedFields, NonModelTypes>;
}

^This excerpt is from @aws-amplify/data-schema/dist/esm/ClientSchema.d.ts

ideen1 avatar May 08 '24 05:05 ideen1

@ideen1 the change to the model types being nested under type was intentional but the description of this issue is a little unclear.

The two snippets you shared are not valid syntax, unless you meant:

(await client.models.Trainer.list()).data[0].id;
image

On the latest versions of aws-amplify, @aws-amplify/backend, and @aws-amplify/backend-cli I was not able to reproduce the issue as it is described. As shown above, when I await the result of a list(), I can access an item and id without going through a type field.

chrisbonifacio avatar May 29 '24 20:05 chrisbonifacio

Hi πŸ‘‹ Closing this as we have not heard back from you. If you are still experiencing this issue and in need of assistance, please feel free to comment and provide us with any information previously requested by our team members so we can re-open this issue and be better able to assist you.

Thank you!

chrisbonifacio avatar Jun 04 '24 16:06 chrisbonifacio

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.

github-actions[bot] avatar Jun 04 '24 16:06 github-actions[bot]