Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Big refactor to separate operation-traversal from code-generation
I've felt for a while that types.go is way too confusing, and as I started to implement some of the more complex cases of generating interface-types, the cracks were really starting to show. Luckily, I also finally realized how to fix it: we need to separate the process of traversing the GraphQL operation and schema to decide what types to generate from the process of actually generating those types. This requires an extra set of intermediate data structures, but I think it makes things quite a lot easier to understand -- and, importantly, it means that the code-generation doesn't need to go in the order we traverse the query/schema. So in this commit, I did that huge refactor. It's probably best to just review types.go and traverse.go as if they were new; the old code was quite hard to understand and the new code will hopefully make a lot more sense. (And to that end, review comments about what could be organized better or needs more documentation are very much in order, even for code that is mostly unchanged.) This does introduce one bug, sort of, which is that rather than generating broken code for list-of-interface fields, we generate no code at all. (A TODO in unmarshal.go describes why.) I'll fix this when I add support for those fields. (It's all behind the AllowBrokenFeatures flag, anyway.) Otherwise, the only changes to generated code are that a few methods are ordered differently, because we now generate the implements-interface methods with the interface, rather than the implementations, as it's much simpler that way. (In GraphQL, unlike Go, we know the list of all possible implementations of each interface, so this is possible.) Test plan: golangci-lint run ./... && go test ./...
- Loading branch information