Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce @wordpress/data package size with implementing native JS functions instead of Lodash #27982

Closed
mdmag opened this issue Jan 5, 2021 · 3 comments
Labels
[Package] Data /packages/data [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed [Type] Performance Related to performance efforts

Comments

@mdmag
Copy link

mdmag commented Jan 5, 2021

I love the @wordpress/data package so much because it really solved major problems at my application and I think it should gain more popularity among the React community. But hey, once I import it, my app size increases drastically.
@wordpress/data package alone is 33kb at the moment.
Here is the list of its dependencies:
1- lodash 73Kb
2- @wordpress/compose 34kb
3- @wordpress/redux-routine 10kb
4- @wordpress/hooks 6kb
5- @wordpress/deprecated 2kb
6- @wordpress/is-shallow-equal 2kb
7- @wordpress/priority-queue 2kb
8- @wordpress/escape-html 2kb
Around 164kb to just use @wordpress/data .. I hope this would be reduced.
I think that lodash is a major part here. I hope to replace the the functions used from lodash with native js implementation.
Here is the list of lodash functions used in @wordpress/data , @wordpress/compose and @wordpress/redux-routine:
{ forEach, without, debounce, includes, castArray, throttle, camelCase, upperCase, omit, get, mapValues, isObject, has ,flowRight, isPlainObject, map, isString, merge }
One short term solution is to change the syntax for lodash import in those packages from:

import { forEach } from "lodash";

to

import forEach from "lodash/forEach";

so if any one uses the package outside WordPress, he may need to have lodash-webpack-plugin but the long term solution is to implement vanilla JS functions instead of lodash functions in those packages: @wordpress/data , @wordpress/compose and @wordpress/redux-routine

@mdmag mdmag changed the title Reduce @wordpress/data package size with Implementing native JS functions instead of Lodash Reduce @wordpress/data package size with implementing native JS functions instead of Lodash Jan 5, 2021
@gziolo
Copy link
Member

gziolo commented Jan 5, 2021

Have you tried replacing lodash with lodash-es in your webpack config? WordPress exposes lodash as a global to be shared between all JS modules so it doesn't need to optimize for the tree-shaking scenario, but in your case, it might help even it initially this package is a bit larger according to https://bundlephobia.com/result?p=lodash-es@4.17.20.

I also think that @ZebulanStanphill did some efforts in the past to use native functions instead of their lodash alternatives. It would definitely help here as well.

Aside: @wordpress/compose is tree-shakeable by default, and it only pulls createHigherOrderComponent and pure methods in @wordpress/data. It happens mostly when you use withSelect and withDispatch which is less popular option than React hooks these days.

@gziolo gziolo added [Type] Performance Related to performance efforts [Package] Data /packages/data labels Jan 5, 2021
@ocean90
Copy link
Member

ocean90 commented Jan 5, 2021

This should probably be closed as a duplicate of #17025. This and #9374 have a lot of discussion about this.

@gziolo
Copy link
Member

gziolo commented Jan 5, 2021

Good catch @ocean90, let's move the discussion there. I copied over the comments.

@gziolo gziolo closed this as completed Jan 5, 2021
@gziolo gziolo added the [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed label Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Data /packages/data [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed [Type] Performance Related to performance efforts
Projects
None yet
Development

No branches or pull requests

3 participants