Bump the redux group with 3 updates

[dependabot]

Bumps the redux group with 3 updates: redux, redux-thunk and reselect.

Updates redux from 4.2.1 to 5.0.0

Release notes

Sourced from redux's releases.

v5.0.0

This major release:

• Converts the codebase to TypeScript
• Updates the packaging for better ESM/CJS compatibility and modernizes the build output
• Requires that action.type must be a string
• Continues to mark createStore as deprecated
• Deprecates the AnyAction type in favor of an UnknownAction type that is used everywhere
• Removes the PreloadedState type in favor of a new generic argument for the Reducer type.

This release has breaking changes.

This release is part of a wave of major versions of all the Redux packages: Redux Toolkit 2.0, Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0.

For full details on all of the breaking changes and other significant changes to all of those packages, see the "Migrating to RTK 2.0 and Redux 5.0" migration guide in the Redux docs.

[!NOTE] The Redux core, Reselect, and Redux Thunk packages are included as part of Redux Toolkit, and RTK users do not need to manually upgrade them - you'll get them as part of the upgrade to RTK 2.0. (If you're not using Redux Toolkit yet, please start migrating your existing legacy Redux code to use Redux Toolkit today!)

# RTK
npm install @reduxjs/toolkit
yarn add @reduxjs/toolkit
Standalone
npm install redux
yarn add redux

Changelog

ESM/CJS Package Compatibility

The biggest theme of the Redux v5 and RTK 2.0 releases is trying to get "true" ESM package publishing compatibility in place, while still supporting CJS in the published package.

The primary build artifact is now an ESM file, dist/redux.mjs. Most build tools should pick this up. There's also a CJS artifact, and a second copy of the ESM file named redux.legacy-esm.js to support Webpack 4 (which does not recognize the exports field in package.json). Additionally, all of the build artifacts now live under ./dist/ in the published package.

Modernized Build Output

We now publish modern JS syntax targeting ES2020, including optional chaining, object spread, and other modern syntax. If you need to

Build Tooling

We're now building the package using https://github.com/egoist/tsup. We also now include sourcemaps for the ESM and CJS artifacts.

Dropping UMD Builds

Redux has always shipped with UMD build artifacts. These are primarily meant for direct import as script tags, such as in a CodePen or a no-bundler build environment.

... (truncated)

Commits

• 549589e Release 5.0.0
• 0dab270 Merge pull request #4629 from reduxjs/docs/5.0-docs-updates
• e222442 Update migration page
• e124f0b Merge pull request #4625 from reduxjs/docs/5.0-docs-updates
• 173ff78 Kill the term "reducing function"
• 3757120 Drop UMD mentions
• 5dcefbe Nuke most "ES2015" references
• ddf44fe Nuke dead "Object spread" page
• 47cf3a5 Add API docs for new utils
• 97d0992 ES2015 all the things!
• Additional commits viewable in compare view

Updates redux-thunk from 2.4.2 to 3.1.0

Release notes

Sourced from redux-thunk's releases.

v3.1.0

This major release:

• Updates the packaging for better ESM/CJS compatibility
• Changes the package to use named exports instead of a default export

This release has breaking changes. (Note: this actually points to v3.1.0, which includes a hotfix that was meant for 3.0.0.)

This release is part of a wave of major versions of all the Redux packages: Redux Toolkit 2.0, Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0.

For full details on all of the breaking changes and other significant changes to all of those packages, see the "Migrating to RTK 2.0 and Redux 5.0" migration guide in the Redux docs.

[!NOTE] The Redux core, Reselect, and Redux Thunk packages are included as part of Redux Toolkit, and RTK users do not need to manually upgrade them - you'll get them as part of the upgrade to RTK 2.0. (If you're not using Redux Toolkit yet, please start migrating your existing legacy Redux code to use Redux Toolkit today!)

# RTK
npm install @reduxjs/toolkit
yarn add @reduxjs/toolkit
Standalone
npm install redux-thunk
yarn add redux-thunk

Changelog

Named Exports Instead of Default Exports

The redux-thunk package previously used a single default export that was the thunk middleware, with an attached field named withExtraArgument that allowed customization.

The default export has been removed. There are now two named exports: thunk (the basic middleware) and withExtraArgument.

If you are using Redux Toolkit, this should have no effect, as RTK already handles this inside of configureStore.

ESM/CJS Package Compatibility

The biggest theme of the Redux v5 and RTK 2.0 releases is trying to get "true" ESM package publishing compatibility in place, while still supporting CJS in the published package.

The primary build artifact is now an ESM file, dist/redux-thunk.mjs. Most build tools should pick this up. There's also a CJS artifact, and a second copy of the ESM file named redux-thunk.legacy-esm.js to support Webpack 4 (which does not recognize the exports field in package.json).

Build Tooling

We're now building the package using https://github.com/egoist/tsup. We also now include sourcemaps for the ESM and CJS artifacts.

The repo has been updated to use Yarn 3 for dependencies and Vitest for running tests.

Dropping UMD Builds

Redux has always shipped with UMD build artifacts. These are primarily meant for direct import as script tags, such as in a CodePen or a no-bundler build environment.

... (truncated)

Commits

• 88008ea Release 3.1.0
• 1de2476 Merge pull request #357 from reduxjs/feature/remove-extend
• c8d4878 Drop the extend-redux addition
• 3da59d0 Release 3.0.1
• d4909d3 Kill the bindActionCreators overload for now
• ece6c25 Release 3.0.0
• b419ba6 Bump Redux dep
• 72db9a6 Release 3.0.0-rc.0
• 0ad3af1 Merge pull request #356 from reduxjs/feature/3.0-bump-deps-rc
• 8863682 Remove old attw matrix entry
• Additional commits viewable in compare view

Updates reselect from 4.1.8 to 5.0.1

Release notes

Sourced from reselect's releases.

v5.0.0

This major release:

• Switches createSelector to use a new weakMapMemoize method as the default memoizer
• Renames the existing defaultMemoize method to lruMemoize
• Adds new configuration options to createSelector
• Adds new development mode checks
• Updates the packaging for better ESM/CJS compatibility and modernizes the build output
• Makes significant updates to the TS types.

This release has breaking changes. (note: this points to v5.0.1, which contains a hotfix that was released prior to the announcement.)

This release is part of a wave of major versions of all the Redux packages: Redux Toolkit 2.0, Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0.

For full details on all of the breaking changes and other significant changes to all of those packages, see the "Migrating to RTK 2.0 and Redux 5.0" migration guide in the Redux docs.

We have a new docs site! The Reselect docs are now at https://reselect.js.org.

[!NOTE] The Redux core, Reselect, and Redux Thunk packages are included as part of Redux Toolkit, and RTK users do not need to manually upgrade them - you'll get them as part of the upgrade to RTK 2.0. (If you're not using Redux Toolkit yet, please start migrating your existing legacy Redux code to use Redux Toolkit today!)

# RTK
npm install @reduxjs/toolkit
yarn add @reduxjs/toolkit
Standalone
npm install reselect
yarn add reselect

Changelog

createSelector Uses weakMapMemoize By Default

Reselect's createSelector originally only had one memoization function, which has originally called defaultMemoize (and per below, is now renamed to lruMemoize). It's always used a customizable comparison method to compare each argument. Over time, we added more functionality, particularly in v4.1.0 where lruMemoize gained options for {memoize, maxSize, resultEqualityCheck}.

However, lruMemoize has limitations. The biggest one is that the default cache size is 1. This makes selector instances hard to reuse in scenarios like list items, which might call selectSomeValue(state, props.id), and thus never actually memoize due to changing arguments. There are workarounds, but they're cumbersome - using createSelectorCreator to create a customized createSelector function with a different memoization implementation, creating unique selector instances per component, or setting a fixed maxSize.

For 5.0, we added a new weakMapMemoize memoization function, which takes a different approach (as originally implemented in the React codebase). It uses an internal tree of cache nodes rather than a single value or a list of values. This gives weakMapMemoize an effectively infinite cache size!

We've done a fair amount of testing, and weakMapMemoize both performs faster and has more frequent cache hits than lruMemoize.

Given that, we've made the switch so that createSelector uses weakMapMemoize by default! This should result in better performance for Redux and React apps that use Reselect.

This is hopefully a mostly non-breaking change at the code level, and an overall improvement at the behavior level.

This is a breaking change. weakMapMemoize does not have an equalityCheck option or allow customizing the comparison behavior - it's entirely based on reference comparisons, since it uses WeakMap/Map internally. It also does not have a maxSize option, but does have resultEqualityCheck.

If you need to customize the overall equality comparison behavior, import and pass lruMemoize as the memoize and argsMemoize option!

... (truncated)

Commits

• cf8d96b Release 5.0.1
• 2a1e055 Merge pull request #657 from reduxjs/bugfix/5.0-weakref-check
• 484626e Drop v2.0-integration checkout
• d2a0cd1 Fix WeakRef check
• 87ac8fb Release 5.0.0
• 3bf2ab4 Merge pull request #656 from aryaemami59/netlify-docs
• cedf7a5 Further README cleanup
• f616572 Update theme to monokai to match other sites
• 31f2228 Update docs site link and tweak content
• a5db189 Memoize some components
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[acelaya]

defaultMemoize has been renamed to lruMemoize, as it's no longer the default: https://github.com/reduxjs/reselect/releases/tag/v5.0.1

[acelaya]

Using the thunk named export now has the right types and redux-thunk/extend-redux is no longer needed (in fact it is no longer included)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (00d7b43) 99.45% compared to head (ab4cbf4) 99.45%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6003   +/-   ##
=======================================
  Coverage   99.45%   99.45%           
=======================================
  Files         265      265           
  Lines       10127    10129    +2     
  Branches     2462     2462           
=======================================
+ Hits        10072    10074    +2     
  Misses         55       55           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[acelaya]

The any at the end represents the actions that dispatch can be called with. It's either a regular action, or the return type of an async thunk callback. In this case we need both.

I could not define an action type that didn't make one of the dispatch(...) calls trigger a type error, so I defined it as ´any´ for now, but we might want to revisit this.

For references, this is ThunkDispatch type definition and docs:

/**
 * The dispatch method as modified by React-Thunk; overloaded so that you can
 * dispatch:
 *   - standard (object) actions: `dispatch()` returns the action itself
 *   - thunk actions: `dispatch()` returns the thunk's return value
 *
 * @template State The redux state
 * @template ExtraThunkArg The extra argument passed to the inner function of
 * thunks (if specified when setting up the Thunk middleware)
 * @template BasicAction The (non-thunk) actions that can be dispatched.
 */
interface ThunkDispatch<State, ExtraThunkArg, BasicAction extends Action> {
    /** Accepts a thunk function, runs it, and returns whatever the thunk itself returns */
    <ReturnType>(thunkAction: ThunkAction<ReturnType, State, ExtraThunkArg, BasicAction>): ReturnType;
    /** Accepts a standard action object, and returns that action object */
    <Action extends BasicAction>(action: Action): Action;
    /** A union of the other two overloads for TS inference purposes */
    <ReturnType, Action extends BasicAction>(action: Action | ThunkAction<ReturnType, State, ExtraThunkArg, BasicAction>): Action | ReturnType;
}

[robertknight]

I think this is pragmatic for now.

[acelaya]

All explicit type errors resulting from updating to new major versions have been addressed.

There's now two warnings left, triggered by two of our selectors, caused by the changes introduced in reduxjs/reselect#645

Both were probably a potential issue before, but they were not checked by previous reselect versions. Applying this diff allows those to not be checked if that's what we want:

diff --git a/src/sidebar/store/modules/frames.ts b/src/sidebar/store/modules/frames.ts
index acb066ad9..864b3acd7 100644
--- a/src/sidebar/store/modules/frames.ts
+++ b/src/sidebar/store/modules/frames.ts
@@ -208,6 +208,11 @@ const searchUris = createShallowEqualSelector(
       [],
     ),
   uris => uris,
+  {
+    devModeChecks: {
+      identityFunctionCheck: 'never',
+    },
+  },
 );
 
 function getContentInfo(state: State) {
diff --git a/src/sidebar/store/modules/real-time-updates.ts b/src/sidebar/store/modules/real-time-updates.ts
index ef1ecdb5f..4d70c6b5e 100644
--- a/src/sidebar/store/modules/real-time-updates.ts
+++ b/src/sidebar/store/modules/real-time-updates.ts
@@ -194,6 +194,11 @@ const pendingUpdateCount = createSelector(
   (state: State) => [state.pendingUpdates, state.pendingDeletions],
   ([pendingUpdates, pendingDeletions]) =>
     Object.keys(pendingUpdates).length + Object.keys(pendingDeletions).length,
+  {
+    devModeChecks: {
+      inputStabilityCheck: 'never',
+    },
+  },
 );
 
 /**

EDIT: The second warning can also be addressed by refactoring real-time-updates's pendingUpdatesCount to not use createSelector at all:

function pendingUpdateCount(state: State) {
  return (
    Object.keys(state.pendingUpdates).length +
    Object.keys(state.pendingDeletions).length
  );
}

[robertknight]

The initial changes from you look good to me @acelaya. I pushed suggested solutions for the two remaining warnings. In one instance I fixed a simple error, in the other I used a warning suppression as it is more complex to resolve the actual issue.

[acelaya]

I pushed suggested solutions for the two remaining warnings. In one instance I fixed a simple error, in the other I used a warning suppression as it is more complex to resolve the actual issue.

Those changes seem sensible to me.