Releases: connectrpc/connect-query-es
v1.4.2
What's Changed
- Remove "module" export condition to prevent confusion with webpack by @paul-sachs in #407
Full Changelog: v1.4.1...v1.4.2
v1.4.1
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
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