v1.4.0

What's Changed

• Need mutation context generic to support passing context by @paul-sachs in #359
• Make sure generated keys include defaults by @paul-sachs in #366

Full Changelog: v1.3.1...v1.4.0

v1.3.1

What's Changed

• Pass abort signal to transport for mutations by @paul-sachs in #351

Full Changelog: v1.3.0...v1.3.1

v1.3.0

What's Changed

• Prevent using extendible input type by @paul-sachs in #345
• Expose internal methods used to create query options by @paul-sachs in #343

Full Changelog: v1.2.0...v1.3.0

v1.2.0

What's Changed

• Add a distinguishing factor between infinite query keys and regular query keys by @paul-sachs in #334
• Add support for enabled to useInfiniteQuery by @paul-sachs in #338

Changes to infinite query keys

With #334, we're fixing a bug where the cache of a regular query collides with the cache of an infinite query, which can lead to type mismatches and unexpected failures if you use the same RPC with an infinite query and a regular query.
We are now using a separate query key for infinite queries to solve the issue (we append "infinite" to the key), but this change can potentially affect you:

If you tried to invalidate some infinite queries like queryClient.invalidateQueries({ queryKey: createConnectQueryKey(...), exact: true }), this now only invalidates queries initialized with useQuery. To invalidate infinite queries, you can either set exact to false, or use createConnectInfiniteQueryKey() instead. Also note that this change not only affects invalidateQueries but any operations against the queryClient that interact with the cache using a key (eg, queryClient.setQueriesData, etc.)

Full Changelog: v1.1.3...v1.2.0

v1.1.3

What's Changed

• Add interceptor example to readme by @paul-sachs in #313
• Make sure to take into account enabled queryOption by @paul-sachs in #318

Full Changelog: v1.1.2...v1.1.3

v1.1.2

What's Changed

• Remove ESM wrapper by @paul-sachs in #312

Full Changelog: v1.1.1...v1.1.2

v1.1.1

What's Changed

• Fix dual package hazard in nodejs by @paul-sachs in #310

Full Changelog: v1.1.0...v1.1.1

v1.1.0

What's Changed

• Update imports to include file extensions by @paul-sachs in #299 and #307
• Added support for cjs output by @paul-sachs in #303
• Loosen peer dependency requirement by @paul-sachs in #306

CJS output

By default, protoc-gen-connect-query (and all other plugins based on @bufbuild/protoplugin) generate ECMAScript import and export statements. For use cases where CommonJS is difficult to avoid, a new plugin option has been added named js_import_style which can be used to generate CommonJS require() calls.

Here is an example buf.gen.yaml:

version: v1
plugins:
  # You'll need @bufbuild/protoc-gen-es v1.6.0 or later
  - plugin: es
    out: src/gen
    opt: js_import_style=legacy_commonjs
  - plugin: protoc-gen-connect-query
    out: src/gen
    opt: js_import_style=legacy_commonjs

To view the full PR, see Added support for cjs output by @paul-sachs in #303

Full Changelog: v1.0.0...v1.1.0

v1.0.0

What's Changed

• V1 API: Wrapping react-query by @paul-sachs in #224

V1 Release 🚀

Introducing a whole new API for connect-query. This API ties itself more tightly with the fantastic @tanstack/react-query in order to improve developer experience and reduce bundle size.

At the core of this change is the new MethodUnaryDescriptor type, which is essentially just a self contained description of a service method. The new code generator just outputs one of these per method and those are passed to the hooks/methods. This new additional type brings a huge level of flexibility about how we write additional methods, and it's trivial to write your own hooks/methods around these simple types.

Example usage

import { useQuery } from "@connectrpc/connect-query";
import { say } from "./gen/eliza-ElizaService_connectquery";

...

const { data } = useQuery(say);

Breaking changes

• use*Query hooks now return data instead of just options.
• Many create* methods have been removed.
• protoc-gen-connect-query now outputs very simple method descriptors instead of a bunch of hooks per method.

Reasoning

There are a number of reasons we've decided to make this major breaking change.

1. The API surface is much smaller, leading to less confusion about how to use each method.
2. Smaller core code size and more modular organization leads to better tree shaking (since each generated method doesn't come along with a generated hook).
3. Package names are now explicit about their dependencies, making it easier to develop other packages based on these packages/generated code.
4. More tightly integrating with @tanstack/react-query@5 provides better usage of Suspense versions of the API.
5. New generated code is easier to expand and build your own custom hooks for.

Migration

The migration process is easy but manual:

Before

import { getUserOrganization } from "@apigen/org/alpha/registry/v1alpha1/organization-OrganizationService_connectquery";
import { useQuery } from "@tanstack/react-query";

...

const getUserOrganizationQuery = useQuery({
    ...getUserOrganization.useQuery({
      userId: currentUser?.id,
      organizationId,
    }),
    useErrorBoundary: false,
    enabled: currentUser !== null,
});

After

import { getUserOrganization } from "@apigen/org/alpha/registry/v1alpha1/organization-OrganizationService_connectquery";
import { useQuery } from "@connectrpc/connect-query";

...

const getUserOrganizationQuery = useQuery(getUserOrganization, {
      userId: currentUser?.id,
      organizationId,
    },
    {
      useErrorBoundary: false,
      enabled: currentUser !== null
    }
});

Full Changelog: v0.6.0...v1.0.0

v0.6.0

What's Changed

• Update to react-query@5 by @paul-sachs in #179

Update to react-query@5

This update contains some breaking changes including, but not limited to:

• Removed onError passed to useQuery, this aligns with the removed event handlers in @tanstack/query
• useInfiniteQuery now requires the initial page param to be defined in the input because initialPageParam is required

Full Changelog: v0.5.3...v0.6.0