Supported nested fields

[Ben-Ho]

open points

• move grid changes into follow-up pull-request
• decide if we should use UsableFields (Supported nested fields #1695 (comment))
• merge extended demo from next and maybe fixed packageDimensions from main
• remove objectSuffix from recursiveStringify
• maybe follow-up pull-request for checkable fieldset? -> conditional-fields will be added later
• handle optional number field bug?

[nsams]

would this work correctly?

packageDimensions: {
    width: number;
    height: number;
    depth: number;
    textfield: string;
    booleanfield: boolean;
    nestingtwo: {
        numberfield: number;
        textfield: string
    }
}

(maybe we should extend the demo)

[johnnyomair]

I had a really hard time reviewing this. Lot's of refactors, lot's of similar functions that are slightly different in detail. Also, most functions are rather hard to read.

Maybe adding more commits for smaller changes would have been preferable?

[Ben-Ho]

I had a really hard time reviewing this. Lot's of refactors, lot's of similar functions that are slightly different in detail. Also, most functions are rather hard to read.

I also underestimated this change. I thought simply improving the types, and handle the dot notation in the query would do the trick, but it needed changes to many places... and it seems it's not even ready now, as I found there are many issues with generated grid...

[Ben-Ho]

would this work correctly?

packageDimensions: {
    width: number;
    height: number;
    depth: number;
    textfield: string;
    booleanfield: boolean;
    nestingtwo: {
        numberfield: number;
        textfield: string
    }
}

(maybe we should extend the demo)

I didn't test this level of nesting, but I think there should be no limit. I'll extend the demo to test this.

[Ben-Ho]

and it seems it's not even ready now, as I found there are many issues with generated grid...

I'm thinking about opening another pull-request for grid-support, but there are some functions required for both implementations. So even if it doubles the changes I think it's similar enough for the argument to keep it together.

[nsams]

I'm thinking about opening another pull-request for grid-support, but there are some functions required for both implementations. So even if it doubles the changes I think it's similar enough for the argument to keep it together.

make it dependent on this one!

[Ben-Ho]

(maybe we should extend the demo)

I came up with some product-related entities containing double nesting and optional fields. should I add it to this PR or with a separate one?

part of schema.gql

type AlternativeAddress {
  street: String!
  streetNumber: Float
  zip: Float!
  country: String!
}

type Address {
  street: String!
  streetNumber: Float
  zip: Float!
  country: String!
  alternativeAddress: AlternativeAddress
}

type AlternativeAddressAsEmbeddable {
  street: String!
  streetNumber: Float
  zip: Float!
  country: String!
}

type AddressAsEmbeddable {
  street: String!
  streetNumber: Float
  zip: Float!
  country: String!
  alternativeAddress: AlternativeAddressAsEmbeddable
}

type Manufacturer {
  id: ID!
  address: Address
  addressAsEmbeddable: AddressAsEmbeddable
  updatedAt: DateTime!
}

[nsams]

should I add it to this PR or with a separate one?

👍 please create a separate PR

[Ben-Ho]

👍 please create a separate PR

done: #1729

[johnnyomair]

Marking this as draft until #1751 and #1759 have been merged.