You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: ROADMAP.md
+30
Original file line number
Diff line number
Diff line change
@@ -53,6 +53,36 @@ _Approximate Date: March 2024_
53
53
- Right now we are naively generating schema types that we don't always need. A smarter algorithm can reduce generated code for certain large schemas that are currently having every type in their schema generated
54
54
- Create configuration for manually indicating schema types you would like to have schema types and TestMocks generated for
55
55
56
+
### [Support codegen of operations without response models](https://github.com/apollographql/apollo-ios/issues/3165)
57
+
58
+
_Approximate Date: TBD_
59
+
60
+
- Support generating models that expose only the minimal necessary data for operation execution (networking and caching).
61
+
- This would remove the generated response models, exposing response data as a simple `JSONObject` (ie. [String: AnyHashable]).
62
+
- This feature is useful for projects that want to use their own custom data models or have binary size constraints.
63
+
64
+
### [Configuration to rename generated models for schema types](https://github.com/apollographql/apollo-ios/issues/3283)
65
+
66
+
_Approximate Date: TBD_
67
+
68
+
- Allow client-side users to override the names of schema types in the generated models.
69
+
- This will allow user's to improve the quality and expressiveness of client side APIs when schema type names are not appropriate for client usage.
70
+
- This also allows workarounds for issues when names of schema types conflict with Swift types.
- Provide a mechanism for making generated reponse models mutable.
77
+
- This will allow mutability on an opt-in basis per selection set or definition.
78
+
79
+
### Custom import statements on generated models
80
+
81
+
_Approximate Date: TBD_
82
+
83
+
- This improves multi-module support by allowing shared fragments located in one module to be imported by definitions that reference them but are located in another module.
84
+
- Currently, fragments shared across modules must be located in the schema module.
0 commit comments