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

Remove lodash dependency from '@wordpress/element' #16938

Open
nerrad opened this issue Aug 7, 2019 · 9 comments

Comments

@nerrad
Copy link
Contributor

commented Aug 7, 2019

Is your feature request related to a problem? Please describe.

One of the challenges for projects that want to use various WordPress packages on the frontend is keeping js bundles small. While lodash itself is small in size, the fact that wp.element depends on it means that any code wanting to enqueue wp.element on the frontend is also going to load lodash.

Since there are many native implementations for lodash features that can be used reliably (and in some cases are faster than lodash), I think it'd be good to remove this package's dependency on lodash and replace with native implementation.

Describe the solution you'd like

Replace lodash dependency in @wordpress/element by reimplementing any lodash features as native js.

@nerrad

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2019

So, the following lodash functions are relatively trivial to re-implement using native js (for the use-case in wp.element):

  • isArray
  • isNumber
  • isString
  • isEmpty
  • castArray
  • startsWith
  • omit

However, there are a couple that are a bit more involved:

  • kebabCase
  • isPlainObject

Since the last two would involve essentially copying in the same thing that lodash did I'm wondering if the effort here is still worth it.

One alternative I've been pondering when it comes to how WordPress exposes libraries now that javascript is more "first-class" is why we don't take advantage of cdn distributed scripts which to some degree can eliminate the concerns of common dependencies such as lodash, react etc. I'm going to bring this up in the next #core-js meeting.

@adamsilverstein

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

Since the last two would involve essentially copying in the same thing that lodash did I'm wondering if the effort here is still worth it.

One other advantage would be avoiding conflicts with other code on the page using lodash or underscore.

However, there are a couple that are a bit more involved:

kebabCase
isPlainObject

These are pretty tiny, can we just import and bundle them (or copy the code directly)?

https://github.com/lodash/lodash/blob/master/kebabCase.js
https://github.com/lodash/lodash/blob/master/isPlainObject.js

@nerrad

This comment has been minimized.

Copy link
Contributor Author

commented Aug 12, 2019

These are pretty tiny, can we just import and bundle them (or copy the code directly)?

They are tiny, but they have dependencies (follow the internal dependency chain for kebabCase for instance). I'm wondering though, if there are only a few lodash helpers like these two, if we should just use the custom builds feature of lodash and create a special WP package (@wordpress/utils ?) for lodash helpers such as kebabCase etc that have a bit more involved code than what can simply be implemented using native js?

@adamsilverstein

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

worth a try, removing the lodash dependency feels pretty valuable, especially in the WordPress admin context.

@swissspidy

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

Is @wordpress/element the only package depending on lodash or are there other places where we might be able to remove the dependency?

@nerrad

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

Is @wordpress/element the only package depending on lodash or are there other places where we might be able to remove the dependency?

It's extensively used in multiple packages in this repository. Ideally it'd be nice to remove it as a dependency everywhere and instead just expose a subset of lodash utils for use (via another package). I'll create another issue for discussing this.

@chrisvanpatten

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

One small concern is that as a third party developer, I've used lodash extensively within my own blocks, using the build provided in core. I can understand the appeal of removing a dependency but it feels like a small price to pay for all of the DevEx improvements it brings. Of course I can provide my own bundle if Gutenberg stops using it (or builds a custom build) but then we've just introduced a bunch of duplication as any plugin using lodash may decide to provide its own bundle.

@chrisvanpatten

This comment has been minimized.

Copy link
Member

commented Aug 13, 2019

(In other words, this feels a bit like seeing the forest for the trees. It's a nice optimization, but what challenges/duplication would it lead to for third-parties?)

@nerrad

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2019

I think for back compat we'd need to keep lodash available as an externally provided script in WP core. So your concern here Chris can be mitigated.

As a flipside to your argument, there is also the challenge of current WordPress packages that have a dependency on lodash unnecessarily which adds additional weight everywhere they are enqueued. This specific pull is an example of that. If someone wants to use wp.element on the frontend (and is not needing any of the lodash functions), lodash is loaded regardless. This is something currently experienced by the WooCommerce blocks team where we don't need lodash functionality in the frontend. This in turn means that for now, we're not using wp.element and just use react and react-dom directly (via what's provided by WP).

Not only that, but I have also experienced issues with third party compatibility on some sites where a plugin or theme a site owner has installed is using lodash on the frontend in one of their bundled scripts directly (not enqueuing what WP provides) which leads to conflicts. It'd be nice to avoid that problem if possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.