Generic maps aren't ergonomic in WRAP 0.1 #7

Activity

1. Niraj-Kamdar commented on May 2, 2023

   

   Niraj-Kamdar

   on May 2, 2023

   Contributor

   More actions

   We should fix this in abi-0.2 when we have support for custom extension types. We should have capability of changing bindings for that and injecting it during codegen process. Since every type can be represented as array, object or scalar, Wasm binding layer should be able to deserialize the type correctly even if it's not marked with extension type marker.
2. namesty commented on May 2, 2023

   

   namesty

   on May 2, 2023

   Last edited by namesty

   More actions

   If we zoom out a bit, my hot take is I think that for right now (abi-0.1) it's just easier not to use the GenericMap extension type at all; and just have something like the following:

   Instead of this:

   type Module {
     mapMethod(
       map: Map @annotate(type: "Map<String!, Int!>")
     ): Map @annotate(type: "Map<String!, Int!>")
   }

   Have this:

   type MapEntry {
     key: String!
     value: Int!
   }
   
   type Module {
     mapMethod(
       map: [MapEntry]
     ): [MapEntry]
   }

   May be more text but:

   • Does not use special syntax
   • No annotations required
   • Doesn't use anything outside Graphql's standard toolkit
   • Won't need special representation or serialization or deserialization
   • No need to explain user how to use it, how to build one (BTreeMap in Rust, wrapped in a polywrap_client::msgpack::Map, etc.)

   These are all burdens for users and for ourselves. I think the complexity of what we introduce with the GenericMap type significantly outweighs the benefit of not needing to access the key or value prop everytime; or having an additional type for each unique key-value combination