Comments (3)
While Hasura is very popular within the Elm community, I guess you'd be reluctant (at best) to build anything that specifically generates code for that one provider within this general purpose library. Then, the obvious move would be to build a library that builds upon this one.
Yes, I think the challenge is that there is a cost for users to learn new features, understand how they work and when to use them and what is available, and navigating through all the (already pretty complicated) generated code to find something else when they need that. I certainly think that building input objects is in general a pain-point in elm-graphql and I'm very interested in making that general functionality easier to use, but I don't see this as the path I want to go down to do that (looking at vendor-specific tools). So this isn't in the scope of what I'd consider to be part of elm-graphql, but of course you're welcome to experiment with building external tools if you think that would be helpful for your use case.
I'm keeping an eye on what Vendr is experimenting with for using the Phantom Builder Pattern to build up input objects (https://rhg.dev/blog/exploring-graphql-input/). I think they still have some problems they'll need to solve that I haven't heard an answer for so far - specifically how to deal with generating functions for working with arguments with the same name but different types within an API. I worry a bit that some of those details could end up being dead ends in that design direction, but I'm really eager to see if they're able to solve those issues because if so it could be really promising.
Otherwise: is there any appetite for adding extension points to this library to generate some extra files? Is that even possible? Maybe a --after Hasura.GenerateHelpers.call CLI hook? Ideally this would still have some state of the schema passed into it.
This is a pretty ambitious feature and I don't see a clear concrete value to it at the moment, so I'm not planning on working on something like this. It would be hard to design something without a very clear reason for it and I would need to see a lot more concrete use cases where this would be beneficial before it would seem compelling to me.
from elm-graphql.
Thanks for the thoughtful reply @dillonkearns. All very reasonable!
Closing this issue.
from elm-graphql.
After sleeping on it, I realized I conflated Graphql with Hasura here ๐
While Hasura is very popular within the Elm community, I guess you'd be reluctant (at best) to build anything that specifically generates code for that one provider within this general purpose library. Then, the obvious move would be to build a library that builds upon this one.
The simplest (zero integration) approach seems to be: create a tool to run after elm-graphql
that looks for X.InputObject.buildInt_comparison_exp
(etc) with the right signature and then creates some files XHelper.Int
. I think populating them in a different namespace is ideal, since I think this library wipes out all of the files each time it's run, is that right? (See below for a way around this constraint)
These primitive helper functions are relatively static so it doesn't necessarily need to be run every time elm-graphql
is run. However, adding new scalars to the schema, even primitive ones, means that new comparison expression functions get generated (e.g.buildFloat_comparison_exp
when a float gets added to the schema). But since these are just convenience functions, that can be a manual additional step when needed.
Also new custom scalars can be also get new comparison functions generated (e.g. Uuid
, Bpchar
), but those don't need to be considered for a first version, since those involve codecs.
Later, the elm-hasura
CLI tool could first pass all its args to elm-graphql
then runs its own pass immediately after that code is generated, rather than being a separate step. This would also let them share a namespace, X.Int
as originally proposed, though I guess you'd prefer it if I stayed out of there thankyouverymuch ๐
Unfortunately this all seems like a lot of work for a minor/moderate convenience. Are there any other obvious convenience function optimizations that could be made assuming the Graphql schema adheres to the Hasura conventions (or any given set of conventions)?
Otherwise: is there any appetite for adding extension points to this library to generate some extra files? Is that even possible? Maybe a --after Hasura.GenerateHelpers.call
CLI hook? Ideally this would still have some state of the schema passed into it.
This same approach could be applied to creating convenience functions for Postgraphile's similar tool, or really any Graphql schema.
I think in the meantime, I'll just make my own ApiHelper
module with an int_eq
function in my codebase as-needed :D
from elm-graphql.
Related Issues (20)
- Enhancement - Add support for Dgraph HOT 1
- non null list of non null list ofโฆ HOT 6
- Include an exhaustive query for each type HOT 3
- elm-graphql generation fails if there are no columns selected (Hasura) HOT 6
- Add operationName to mutation request body HOT 1
- Enum with underscore as a leading character, changed after generating elm code. HOT 1
- Scalar decoder fails when the field contains an object. HOT 1
- Scalars should not be encoded as json in mutations HOT 3
- Enforce nonempty list in required list arguments HOT 3
- Selecting implementation attributes from interfaces HOT 2
- Corrupt package data for 5.0.5? HOT 1
- Requesting feedback on the following changes to the serializeChildren function regarding field hashing HOT 2
- Can not find ScalarCodecs HOT 1
- Idea: serialize invalid JSON Input Values as arguments
- Missing fragment in Interface `Fragments` type HOT 1
- Idea: include deprecation warnings into the generated code as comments HOT 1
- Building large queries takes a long time and pauses the UI HOT 2
- Encode function for enums is missing HOT 1
- Generate input object helpers HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from elm-graphql.