v1.0.0

Major Release

• #20 ba47907 Thanks @lukemorales! - ## Generate query options and add support for nested keys

  New in @lukemorales/query-key-factory is support for nested keys and generation of query options, adopting the query options overload as first class citizen, in preparation for React Query v5 roadmap.

  const people = createQueryKeys('people', {
    person: (id: number) => ({
      queryKey: [id],
      queryFn: () => api.getPerson({ params: { id } }),
      contextQueries: {
        ships: {
          queryKey: null,
          queryFn: () =>
            api.getShipsByPerson({
              params: { personId: id },
            }),
        },
        film: (filmId: string) => ({
          queryKey: [filmId],
          queryFn: () =>
            api.getFilm({
              params: { id: filmId },
            }),
        }),
      },
    }),
  });

  Each entry outputs an object that can be used in the query options overload in React Query:

  console.log(people.person('person_01'));
  
  // => output:
  // {
  //   queryKey: ['people', 'person', 'person_01'],
  //   queryFn: () => api.getPerson({ params: { id: 'person_01' } }),
  //   _ctx: { ...queries declared inside "contextQueries" }
  // }

  Then you can easily just use the object in useQuery or spread it and add more query options to that observer:

  export const Person = ({ id }) => {
    const personQuery = useQuery(people.person(id));
  
    return {
      /* render person data */
    };
  };
  
  export const Ships = ({ personId }) => {
    const shipsQuery = useQuery({
      ...people.person(personId)._ctx.ships,
      enabled: !!personId,
    });
  
    return {
      /* render ships data */
    };
  };
  
  export const Film = ({ id, personId }) => {
    const filmQuery = useQuery(people.person(personId)._ctx.film(id));
  
    return {
      /* render film data */
    };
  };

  BREAKING CHANGES

  Standardized query key values

  All query key values should now be an array. Only the first level keys (those not dynamically generated) can still be declared as null, but if you want to pass a value, you will need to make it an array.

  export const todosKeys = createQueryKeys('todos', {
    mine: null,
  - all: 'all-todos',
  + all: ['all-todos'],
  - list: (filters: TodoFilters) => ({ filters }),
  + list: (filters: TodoFilters) => [{ filters }],
  - todo: (todoId: string) => todoId,
  + todo: (todoId: string) => [todoId],
  });

  Objects are now used to declare query options

  You can still use objects to compose a query key, but now they must be inside an array because plain objects are now used for the declaration of the query options:

  export const todosKeys = createQueryKeys('todos', {
  - list: (filters: TodoFilters) => ({ filters }),
  + list: (filters: TodoFilters) => ({
  +   queryKey: [{ filters }],
  + }),
  });

  Generated output for a query key is always an object

  With the new API, the output of an entry will always be an object according to what options you've declared in the factory (e.g.: if you returned an array or declared an object with only queryKey, your output will be { queryKey: [...values] }, if you also declared queryFn it will be added to that object, and contextQueries will be available inside _ctx):

  export const todosKeys = createQueryKeys('todos', {
    todo: (todoId: string) => [todoId],
    list: (filters: TodoFilters) => {
      queryKey: [{ filters }],
      queryFn: () => fetchTodosList(filters),
    },
  });
  
  - useQuery(todosKeys.todo(todoId), fetchTodo);
  + useQuery(todosKeys.todo(todoId).queryKey, fetchTodo);
  
  - useQuery(todosKeys.list(filters), fetchTodosList);
  + useQuery(todosKeys.list(filters).queryKey, todosKeys.list(filters).queryFn);
  
  // even better refactor, preparing for React Query v5
  + useQuery({
  +   ...todosKeys.todo(todoId),
  +   queryFn: fetchTodo,
  + });
  
  + useQuery(todosKeys.list(filters));

  Helper types to infer query keys in the store reflect the new output

  The helper types to infer query keys in the created store reflect the new output, to account for all possible use cases:

  type TodosKeys = inferQueryKeys<typeof todosKeys>;
  
  - type SingleTodoQueryKey = TodosKeys['todo'];
  + type SingleTodoQueryKey = TodosKeys['todo']['queryKey'];

• #20 ba47907 Thanks @lukemorales! - ## Remove deprecated methods
  Since v0.6.0, the default key and and toScope method have been deprecated from the package.

  BREAKING CHANGES

  default and toScope removed from implementation

  default key and toScope method have been officially removed from the code, which means that if you try to access them, you will either receive undefined or your code will throw for trying to invoke a function on toScope that does not exist anymore.

What's Changed

• fix: remove arrays from being proxied by @lukemorales in #16
• feat!: generate query options and support nested keys by @lukemorales in #20
• docs: fix typo in README by @jayhawk24 in #22
• feat: allow declaring query options with only queryKey by @lukemorales in #23
• feat: update infer type helpers to work with new API by @lukemorales in #24
• chore(changesets): bump package version by @github-actions in #21

New Contributors

• @jayhawk24 made their first contribution in #22
• @github-actions made their first contribution in #21

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

v0.6.1

Changes

• fix: remove arrays from being proxied by @lukemorales in #16

Full Changelog: v0.6.0...v0.6.1

v0.6.0

Changes

• refactor: introduce _def and deprecate default and toScope by @lukemorales in #14

Full Changelog: v0.5.0...v0.6.0

v0.5.0

Changes

• feat: create `createQueryKeyStore` by @lukemorales in #12

Full Changelog: v0.4.0...v0.5.0

v0.4.0

Changes

• feat: create mergeQueryKeys util by @lukemorales in #11

Full Changelog: v0.3.2...v0.4.0

v0.3.2

Changes

• feat: create inferQueryKeys type by @joaom00 in #9

Full Changelog: v0.3.1...v0.3.2

v0.3.1

Changes

• fix: repaired new factory types published on v0.3.0 (resolves #10)
• docs: update example usage in README by @Shajansheriff in #7

New Contributors

• @Shajansheriff made their first contribution in #7

Full Changelog: v0.3.0...v0.3.1

v0.3.0

Changes

• feat: allow tuples of any size in dynamic keys by @lukemorales in #5

Full Changelog: v0.2.1...v0.3.0

v0.2.1

Changes

• Remove yarn engine restriction, fixes #3

v0.2.0

Changes

• Make serializable keys less strict