Skip to main content

The Isograph team is super excited to announce the release of Isograph v0.3.0, and a follow-up v0.3.1! The amount of features we stuffed into these releases is just absolutely massive. If we went into depth on each one, this blog post would simply be too long — so we're only covering each item in brief!

Interested in trying Isograph out? Check out the quickstart, join the Discord and watch the presentation at GraphQL conf.

Big picture​

These releases improve the usability of Isograph for real-world projects. They include massive internal refactors that bring Isograph closer to a cross-platform world. And they include contributions from five new developers!

Detailed release notes​

In these two releases, you'll find:

Support for Relay-style connection spec pagination​

We've added a useConnectionSpecPagination hook that makes working with Relay-style connections a breeze. Check out the GitHub demo for an example of it in action.

Fetch policies​

APIs for fetching data, such as useLazyReference and useImperativeReference, now accept a fetch policy. Using a fetch policy, you can specify that you would like to unconditionally make a network request, to make it if there isn't enough data in the store to fulfill the entire query, or to not make the network request.

Support for refining to a concrete type and unions​

GraphQL unions and interfaces are now given special fields, asConcreteType fields, which are non-null if the union/interface has that concrete type. For example, you might select asUser on an object of type Node.

onComplete and onError callbacks​

APIs for fetching data, such as useLazyReference and useImperativeReference, also accept onComplete and onError callbacks. These give you the ability to execute a callback when a network request completes or errors out.

We lifted the requirement that IDs are globally unique​

Isograph no longer requires IDs to be globally unique. Instead, they only must be unique within a given typename.

Each object type has a magic link field, which acts as a pointer to that object. So, for example, in node(id: "4") { asUser { link } }, the link field would be { __typename: "User", __link: "4" }.

Compiler watch mode performance improvements​

Our compiler watch mode is now more efficient, and reuses more intermediate results. This is just a taste of things to come — expect massive efficiency gains in the next release 😈.

Massively improved docs​

Our docs have been overhauled. This task will never be done, but there are some serious improvements there.

A demo of using Isograph with Vite​

Isograph can be used with any build framework, but so far, all of our demos have used NextJS. Now, we have a Vite demo.

Other features​

  • There are numerous additional validations, such as that there are no undefined or unused variables. Variables are also typechecked.
  • There are improved component prop types
  • We log when an environment is created
  • Additional Isograph config options:
    • You can use the generated_file_header option to specify a comment that the Isograph compiler should include in generated files. This can be used to disable auto-formatting, linting, etc.
    • The module option controls whether the Babel transform, when encountering entrypoints, will generate require calls or import statements.
    • The include_file_extensions_in_import_statements option controls whether generated files refer to other files with or without file extensions.
    • The no_babel_transform option can be set to true if you don't have the babel transform set up.
  • Our demos now showcase proper error handling.
  • Isograph now has a peer dependency on React 18 or 19, and is not pinned to a specific version of React.

Bug fixes​

  • The component cache had a bug that involved components defined on interfaces and items of different types with identical IDs. (Remember, IDs are no longer required to be globally unique.)
  • We fixed a long-standing issue in which errors during SSR caused infinite suspense, instead of showing an error fallback.

Other internal improvements​

  • We cut down on re-renders by having Isograph re-use parts of the old read out value. To my knowledge, this is done in a cutting edge way: by using the reader AST, and (though we have no benchmarks) is potentially more performant than any other solution.
  • We did a substantial refactor that prepares Isograph to be able to generate SQL, OpenAPI, or any other type of query!
  • We added fixture tests for added stability.

Contributors​

I want to thank the many contributors that helped make this release possible:

And I want to thank the following folks who provided extremely valuable feedback:

The Isograph family is growing 😊

Conclusion​

Whew! If you made it this far, congratulations! But I promise you — subsequent releases will be even more filled with features!

So why not give it a try? Check out the quickstart, join the Discord and watch the presentation at GraphQL conf.

Want to learn more about Isograph? We recently did some deep dives into how the runtime works and how the compiler works!

Another year, another tremendous milestone!

Words cannot express how excited the Isograph team is to announce the release of Isograph 0.2.0. This release is chock full of features, including:

  • fully-featured @component client fields
  • automatic typing
  • compiler watch mode
  • @loadable fields
  • pagination
  • network error handling
  • fragment variables
  • garbage collection
  • fine grained re-rendering
  • support for Windows
  • finer control over re-exposed fields

Let's run through each of these in turn!

What a milestone! Today, the Isograph team is thrilled to announce the release of Isograph 0.1.0. Isograph is ready for use on certain projects and internal tools, and though feature incomplete, provides a great developer experience!

And on top of that, we're releasing this brand new documentation website!

So go on! Take it for a spin. Everything you need to give Isograph a try is in the quickstart guide.

Robert Balicki

Please check out this Substack article announcing Isograph! This article covers the intended developer experience of Isograph, and future features, such as:

  • magic mutation fields (though not called such in the article),
  • deferred resolvers,
  • entrypoints, and
  • injected analytics code.

It also makes the case that Isograph will be well-suited for apps that prioritize correctness, because:

  • type of every field is very informative (e.g. the type of a field might indicate whether the field was unfetched, errored, null or present), and
  • precise control over how to handle each state (e.g. to suspend when reading the resolver if the field is unfetched).

Thank you!