1.1.0-beta.5

[shuding]

Minor Changes

• Mark data and error as readonly: chore: Mark returned states and mutate callback argument as readonly #1514
• Add revalidateFirstPage option to infinite: Add revalidateFirstPage option to swr/infinite (#1401) #1538

Patches

• Output code coverage: chore: Output test code coverage #1511
• Test: Add tests for reconnect and merge-config: test: Add tests for reconnect and merge-config #1530
• Fix: Only trigger the success event if not discarded: fix: Only trigger the success event if not discarded #1529
• Chore: Code refactoring: chore: Code refactoring #1533
• Fix: Reusing cache provider: fix: Reusing cache provider #1539
• Chore: fix ts comments: chore: fix ts comments #1540
• Fix: Ensure mutate accepts undefined as the data: fix: Ensure mutate accepts undefined as the data #1515

Credits

Huge thanks to @timas130 and @huozhi for helping!

---

This discussion was created from the release 1.1.0-beta.5.

[crushjz]

I just updated to 1.1.0-beta.5 and I've encountered some issues regarding the:

Mark data and error as readonly: chore: Mark returned states and mutate callback argument as readonly #1514

I think it's a huge breaking change (not it terms of behavior but in terms of types :)) due to how the ReadonlyArray/Array behaves in TypeScript.

In TypeScript I can pass a Readonly<T> to a function that accepts a T as a parameter. So something like this will work (and will keep working after upgrading to 1.1.0):

type User = {
  id: string;
  email: string;
  name: string;
};

const getUserEmail = (user: User) => user.email;

const useUser = (id: string) => useSWR<User>(`.../${id}`);

const UserComponent: React.VFC = () => {
  const { data: user } = useUser("123");
  //             ^ user will be of type `Readonly<User> | undefined`
  // I can pass `user` to `getUserEmail` email without any type check error
  const userEmail = user ? getUserEmail(user) : "";

  return <>{userEmail}</>;
};

That is not true when using arrays. I cannot pass a ReadonlyArray<T> to a function that accepts a Array<T> as a parameter. So the following example will have type errors:

type ConnectedUsers = Array<User>;

const getConnectedUsersEmails = (users: Array<User>) =>
  users.map((u) => u.email);

const useConnectedUsers = () => useSWR<ConnectedUsers>(`...`);

const ConnectedUsersComponent: React.VFC = () => {
  const { data: users } = useConnectedUsers();

  const usersEmails = users ? getConnectedUsersEmails(users) : [];
  //                                                   ^ Argument of type 'readonly User[]' is not assignable to parameter of type 'User[]'
  return (
    <>
      {usersEmails.map((email) => (
        <div>{email}</div>
      ))}
    </>
  );
};

This is a pain because if we want to use the getConnectedUsersEmails to accept the ReadonlyArray type, we need change also all the functions that getConnectedUsersEmails uses. It's a cascade change. If one of those functions is coming from a 3rd party library, we have to use type assertions to change the Array type to ReadonlyArray since we don't have control over its types.

Check out this codesandbox to see the TS errors: https://codesandbox.io/s/useswr-readonly-return-type-issues-sqyzn?file=/src/App.tsx

In our project we enforce immutability by using the eslint functional plugin, specifically with functional/immutable-data. We found that using ReadonlyArray is a pain when dealing with 3rd party libraries, since most of them use Array instead of ReadonlyArray even if they don't do any mutation.

[shuding]

Thank you so much for reporting this, @crushjz! I did a brief research and it seems there's no easy workaround. In that case we will have to revert it before releasing as stable.

[shuding]

Maybe we have to add this in 2.0 as a breaking change. Still think it’s worth as it prevents some potential bugs…