apollo-client VS redux-toolkit

Actually, it's worse than that. Next has started throwing errors if it statically detects you even _importing_ hooks inside of a React Server Component environment:

- https://github.com/apollographql/apollo-client/issues/10974

- https://github.com/apollographql/apollo-client/issues/11167

To the point that Lenz Weber( a maintainer of Apollo Client, and my co-maintainer on Redux Toolkit), is considering resorting to a package that wraps and re-exports all of React's public API just to avoid that static analysis:

- https://github.com/apollographql/apollo-client/pull/11175

Apollo Client (18k ⭐) -> A comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. Use it to fetch, cache, and modify application data, all while automatically updating your UI.

This currently doesn't work as expected so I have logged this issue in apollo client repo.

I understand this has something to do with the fact, that SvelteKit expects the client and server code to be completely identical - this has already prompted changes to rxjs and apollo is still pending to be fixed. I understand the reason behind being able to run rxjs and apollo on the server but

There is a long-standing issue with error caching (its absence, that is), which leads to errors being rendered as a loading state on the server side. Therefore, if you're doing SSR, you might want to design your schema in such a way that there are no intentional errors in queries whatsoever. To do so, we can use null values instead of NOT_FOUND errors (see how we essentially treated errors as data here?). Note how nothing stops us from setting the response code to 404 in case of a null value, should we want so.

Lol apollo client too.. saw this issue opened like, immediately after the release https://github.com/apollographql/apollo-client/issues/10231

There were some caching issues, outlined here https://github.com/apollographql/apollo-client/issues/6916 to be aware of

If you look at how major backend projects structure their code, it's almost always object-oriented TypeScript.

I submit for the record:

- Apollo Client: https://github.com/apollographql/apollo-client/blob/main/src...

- Storybook: https://github.com/storybookjs/storybook/blob/next/lib/chann...

- Nest: https://github.com/nestjs/nest/blob/master/packages/core/nes...

- MongoDB Driver: https://github.com/mongodb/node-mongodb-native/blob/main/src...

- Prisma: https://github.com/prisma/prisma/blob/main/packages/engine-c...

[※Alert: The following is a code example using the Apollo Client notation, but the Apollo Client does not support Suspense at this time. Github issue about Suspense support: https://github.com/apollographql/apollo-client/issues/9627]

In my example I am using Redux Toolkit and I got a prompt for actions to login and logout the user. If I need more functions, I can simply start typing the name, and Copilot provides the completion. For instance, in the example, I'm adding a function to update the user. And of course at the end of the file it suggests the exports.

Check out the official documentation.

Redux Toolkit 2.0

Redux Toolkit 2.0 is almost here! Hopefully shipping by this weekend :) Migration page

I am _thrilled_ to announce that:

Redux Toolkit 2.0 is LIVE!!!

- https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0

This major version has new features, faster perf, smaller bundle size, and removes deprecated options.

It's accompanied by majors for all our Redux family packages

## RTK 2.0:

- a new `combineSlices` method for lazy-loading reducers - Updates to `createSlice` to include a `selectors` field and allow defining thunks inside

- Immer 10 w/ faster updates

- Removal of deprecated options

See the migration guide:

- https://redux.js.org/usage/migrations/migrating-rtk-2

All of the Redux libraries now have modernized packaging with full ESM/CJS compat. They also ship modern JS (no transpiling for IE11), which means smaller bundle sizes.

We've also done byte-shaving work to shrink the bundles (extracting error messages, de-duping imports)

## Redux core 5.0:

- The TS conversion we did in 2019!

- Action types _must_ be strings

- `UnknownAction` as the default action type

- Better preloaded state types

- Internal subscription improvements

- Still marks `createStore` as deprecated!

- https://github.com/reduxjs/redux/releases/tag/v5.0.0

## React-Redux 9.0:

- *Now requires React 18 and RTK 2.0 / Redux 5.0*

Oh hey, that's my post!

(yes I spend too much time refreshing HN :) )

FWIW I did end up with a packaging combination that seems to work sufficiently. I never did fix the "FalseCJS" issue that `are-the-types-wrong` is detecting. I played with double-emitting TS typedefs, and the `tsup` tool _does_ actually have support for that now (added by Andrew Branch from the TS team). So it might be more feasible now. But ultimately I decided I was tired of messing with packaging setup and that what I've got is good enough. (hopefully)

We're actually about to launch Redux Toolkit 2.0 and Redux 5.0 this week, assuming the last couple pieces come together. Here's the latest RCs - you can see the current `package.json` files in there:

- https://github.com/reduxjs/redux-toolkit/releases/tag/v2.0.0...

- https://github.com/reduxjs/redux/releases/tag/v5.0.0-rc.1

However, Redux, or pure Redux to be specific, can be quite verbose and boilerplate-heavy. It requires a significantly lengthy setup, which is where Redux Toolkit comes in handy, offering a simplified and more efficient way to set up and manage state in your React applications.

State manager is a tool or library that helps manage the state of an application. It provides a centralized store or container for storing and managing data that can be accessed and updated by different components in the application. A state manager solves several problems. Firstly, it is a good practice to separate data and the logic related to it from components. Secondly, when using local state and passing it between components, the code can become convoluted due to the potential for deep nesting of components. By having a global store, we can access and modify data from any component. Alongside React Context, Redux or MobX are commonly used as state management libraries. Learn more Learn more