Closed fabiankaegy closed 2 years ago
There is a more high-level issue that opened a long time ago: https://github.com/WordPress/gutenberg/issues/17025. I think there is a common agreement that we could replace lodash
usage with native API wherever applicable. Should we consolidate the issue with the other one and close this one as duplicate?
There is also https://github.com/WordPress/gutenberg/issues/16938 that is still open for @wordpress/element
so it might need some more thinking on how we approach this growing inconvenience.
For reference, this here is the only instance of lodash
being used in the @wordpress/url
package:
String.prototype.trim() is a simple one to use as replacement.
deburr
is a more tricky one.
We could probably have to re-implement remove_accents
in JS and get rid of deburr
.
Few folks also pointed out that deburr
doesn't handle accent removal correctly.
@Mamaduka I didn't know that PHP function existed. If we were to port it to JS where should it live? 🤔 Would it be it's own @wordpress/
package or should it live under compose
/ i18n
?
Do we use it outside of @wordpress/url
? Otherwise, it can be internal for now.
deburr
seems to be used in 9 files across the entire repo: https://github.com/WordPress/gutenberg/search?q=deburr
But the usage in the url
package is the only one I would consider one in a public package meant for consumption outside of the editor
We could potentially replace most of them with updated cleanForSlug
.
We could potentially replace most of them with updated
cleanForSlug
.
The question would be if making @wordpress/url
a dependency makes sense in all cases.
The question would be if making @wordpress/url a dependency makes sense in all cases.
Probably not, but we don't need to replace them all. We can start with cases where strings are used for slugs.
@wordpress/url
alone is 3.78 kB without lodash
according to https://bundlephobia.com/package/@wordpress/url@3.5.1.
Probably not, but we don't need to replace them all. We can start with cases where strings are used for slugs.
I think that would be a good first step. We can decide later whether it makes sense to extract to its own package.
I'm planning to start working incrementally on removing Lodash completely from the repository. Usage is not so high, and the bundle size impact will be huge for some of the packages when used externally.
@tyxla That is awesome to hear <3
The biggest hurdle for me when looking into removing lodash from the @wordpress/url
package was that I couldn't find a great replacement for the deburr
function.
If you find a way to remove that dependency that will have a huge impact on the ability to use various @wordpress/
packages on the frontend of a site.
Good to know @fabiankaegy 👍 We'll most likely end up having to introduce either a few new utility functions or reusing some well-established implementations that are broadly adopted by the community. deburr
is definitely one of those, but throttle
and debounce
also immediately come to mind when talking about this. We'll get to them all eventually.
I took a shot at https://github.com/WordPress/gutenberg/issues/39495#issuecomment-1069107816 but failed because I don't really have a good enough understanding of the underlying text encoding.
Interesting. Luckily, a few years ago I did implement an almost exact replica of the WP core remove_accents()
for a side project: remove-accents.
It seems to be used quite extensively, and I couldn't be happier to spend more time maintaining it than if it was used in Gutenberg. It could be one way to get rid of deburr()
usage, even if it meant releasing a new version with some improvements.
I'm interested to tackle this one as I'm currently focusing on Lodash removal.
This one should be resolved by #41687
The
@wordpress/api-fetch
package is super useful even outside of the context of the editor. In theory it would be a great package to use on the frontend of any WordPress site to interact with the WordPress Rest API.Currently however it relies on the
@wordpress/url
package which intern has a dependency onlodash
. Because of that the size of the@wordpress/api-fetch
npm package is230 kB
making it un suitable for the sage on the frontend.