Misc discussion thread

[harrysolovay]

I've enjoyed our chats in TypeScript issues. I see you're also a "cuber" (cool simulator!). Gqx looks auspicious as well.

You don't list a name, Twitter handle, etc. anywhere on your GitHub profile or project manifests.

Perhaps this is an unusual request, but I'd love to know who is behind the screen & make sure to stay posted. If you'd prefer to stay anonymous, I completely understand & respect your wishes!

Kind regards

[tjjfvi]

I'm just a random developer who enjoys typescript, cubing, and 3d printing.

gqx is a (very unpolished) library I've been working on that aims to provide a type-safe, implementation-agnostic way to express, communicate, and instantiate GraphQL fragments. For example,

const authorFrag = Author.$(
  Author.id,
  Author.name,
);

const bookFrag1 = Book.$(
  Book.id,
  Book.title,
  Book.author.name,
);

const bookFrag2 = Book.$(
  Book.id,
  Book.author.$(authorFrag)
);

const bookFragCombined = Book.$(
  bookFrag1,
  bookFrag2,
);

gqx.query.getBook({ id: "abc" }, bookFragCombined).then(book => {
  book; // Hover
  /*
    (parameter) book: {
      __typename: "Book";
      id: string;
      title: string;
      author: {
        __typename: "Author";
        id: string;
        name: string;
      };
    }
  */
})

Playground Link (Very unresponsive to edits; I recommend throwing into a vscode tab)

It also spews out lots of generic info about the graphql schema (both in types and runtime objects), which I've used in a couple projects to type tangental aspects of the gql schema, like resolver types.

[harrysolovay]

That looks beautiful! Have you ever experimented with TS-first approaches to schema definition as well?

[tjjfvi]

Thanks! If you're referring to type-level schema parsing, I haven't much. Though I very much like the concept theoretically, since it seems like they aren't going to support it, I think it might be more trouble than it's worth, especially since I prefer to have my schema in separate .graphql files in a folder; I just have a script set up to watch the folder and run gqx every time it changes.

gqx is actually the reason I moved to typescript from flow; I had been trying to implement the frag -> type for days in flow and had been unsuccessful (circular recursion had weird bugs), but I was able to open a typescript playground window and implement it in like an hour. I haven't looked back!

[tjjfvi]

@harrysolovay I thought this might interest you: https://github.com/dotansimha/graphql-typed-ast

[harrysolovay]

I guess this is to be our unofficial chat :)

Apologies for the delay. Lots & lots of work.

That repo absolutely did interest me! It was in fact a catalyst for my current project. I've been building a spec-compliant type-level GQL parser, and those recursion limits are brutal. Can barely parse a 30 loc schema without hitting limits. Also, the lack of throw types (proposed here) makes parse errors a pain: one needs to create a spec-incompliant node kind to contain errors, recursively extract all error nodes from the final tree, and display them with shady tricks (["error message 1", "error message 2"] is not assignable to "false").

Those HKT hacks you've been sharing seem promising! I find it hard to imagine that Ryan's comments against type-level parsers will stick... it would be such a beautiful way to tie together languages in a single env. One way or the other, 4.1 will be of huge benefit to GraphQL-in-TS tooling. I can see you've been thinking about the same problem space. Let's post in this issue whenever we want feedback from one another.

What've you been hacking on? Any cool issues I should take a look at?

[harrysolovay]

Also, any thoughts on this issue? I feel like we're still writing conditional types like cave people ;)

[tjjfvi]

@harrysolovay Yeah, I saw it the other day and I agree that it would be nice. I started to write up a comment for it, but it must have ended up unsent among my tabs 😄

[tjjfvi]

Oh, I didn't see your earlier comment.

Yeah, throw types are a must for complex recursive conditional types, though IMO they should be assignable like never, as that is what people use right now, and them being the "anti-any" messes up passing conditionals involving them to constrained type parameters.

The problem that I've been running into with the HKT hacks is that if you have an HKT that increases the depth by e.g. 10, you have a lot less depth to work with than one that increases the depth by e.g. 1. I've been thinking about if there would be a way for it to detect that it hit depth limit (sometimes if the recursive type is wrapped, the error doesn't propagate and just returns any), backtrack, and repeat, to get the maximum possible recursion depth, but I haven't tried implementing such yet.

I've recently been playing around on the discord with a ConvertibleTo type (best explained by an example), and have been trying to get typescript to recognize this "axiom":

type Axiom<A> = Assert<ConvertibleTo<A>, ConvertibleTo<ConvertibleTo<A>>>

Eventually I got to this, but it would be nice to be able to do it in a more general way.

Wrt interesting issues, I personally think microsoft/TypeScript#41370 is a pretty big type hole, though I may be biased :)

[harrysolovay]

Wow! That is absolutely a hole. Surprised I haven't encountered this limitation before.

I like that ConvertibleTo type! That could come in handy for building libs promoting trait-style patterns in TS. Aka, instead of a subtype check, you'd want to ensure convertibility as a "bound".

... which has me thinking... we need conditional assignability, badly.

[tjjfvi]

Yeah, that's exactly what I'm using/developing it for :)

Yeah, we really do.

[tjjfvi]

Also useful for the trait-style lib is what I've been using in my project to handle plugins:

// Main library
declare global {
  namespace someLibrary {
    interface Conversions {
      aToB: Conversion<A["id"], B["id"]>
    }
  }
}

// In some plugin
declare global {
  namespace someLibrary {
    interface Conversions {
      myPlugin: {
        bToA: Conversion<B["id"], A["id"]>
        misc: (
          | Conversion<B["id"], C["id"]>
          | Conversion<X["id"], Y["id"]>
        )
      }
    }
  }
}

Playground Link

[harrysolovay]

This might take me a little while to grok. Is myPlugin the "trait"? What is the mental model?

[tjjfvi]

That was an alternative for my:

type Conversions = 
  | Conversion<A["id"], B["id"]>
  | Conversion<B["id"], A["id"]>
  | Conversion<B["id"], C["id"]>
  | Conversion<X["id"], Y["id"]>

AFAIK, unions cannot have multiple declarations / be extended.

Instead, I use an interface, and then to form the union of all conversions, I deeply get the values of the interface:

type ConversionsUnion<C = someLibrary.Conversions> = {
  [K in keyof C]: C[K] extends Conversion<any, any> ? C[K] : ConversionsUnion<C[K]>
}[keyof C]

With this, plugins can add conversions by extending the global interface someLibrary.Conversions.

The keys are irrelevant, and just have to be unique so they don't conflict between plugins; I allow it to be deep just for easier namespacing.

[tjjfvi]

A, B, C, X, and Y are the different types, and the Conversions interface just represents the relationships between them.

[harrysolovay]

I see! How do you––at the type-level––safeguard against plugins providing conflicting conversions for the same to types? (I'm assuming there's a runtime component which injects properties in the module being augmented?)