Migrate away from Lodash #4483
Replies: 2 comments
-
Go for it.
I wonder how tree shaking changes the bundle size. In theory you should be
able to shake off most of lodash in your app? I haven't measured that
myself though.
…On Sun, May 5, 2024, 10:19 Marton Sari ***@***.***> wrote:
Hey guys,
First of all, thanks for this amazing project.
Now, I was checking the bundle analysis of our app and lodash stood out as
a large, bulky shameful area. Turns out Recharts is guilty. It's a sad
realization, especially in light of the tagline on the homepage, which
proudly claims that Recharts is a "*lightweight dependency on D3
submodules*."
It's definitely an unreasonable chunk in Rechart's footprint, with
relatively small benefit. Modern JS doesn't really need it, and although I
saw the individual imports, it's notoriously hard to slim down the Lodash
dependency because of its centralized architecture.
I've checked the imports, and I found not too many things, mostly
isFunction and a few others, which are easy to replace with an ad-hoc
implementation. First I'll try to replace them with a pnpm alias as a quick
solution to see if my use case works.
I wouldn't dare venturing into a PR, because I can't check for all the use
cases, but I'll let you guys know how it went for me.
—
Reply to this email directly, view it on GitHub
<#4483>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIMTCWGD76W3SP5V7N2KYTZAWCKTAVCNFSM6AAAAABHHIT5EKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGYYDONBVG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Yeah, just want to say that the current maintainers didn't bring lodash in nor have the capacity to make it go away. At this point it exists in the code because it is easy, it works, and it's reliable. That tagline also existed before the current maintainers and lightweight recharts currently is not. We can change that if we want to not be guilty of misleading people 😅. As for refactoring away from it, sure. If you or someone would like to doing so please feel free. I'm mostly interested in preventing regressions and making sure things are tested to the best of our ability because historically they haven't been and that's been painful. As Pavel mentioned, tree shaking does reduce bundle size by quite a bit and I'd imagine most packaged applications do that to some level these days. I'd be interested in a little comparison there.
Really and truly please do, if anything we review it and work together to cover all the usecases |
Beta Was this translation helpful? Give feedback.
-
Hey guys,
First of all, thanks for this amazing project.
Now, I was checking the bundle analysis of our app and lodash stood out as a large, bulky shameful area. Turns out Recharts is guilty. It's a sad realization, especially in light of the tagline on the homepage, which proudly claims that Recharts is a "lightweight dependency on D3 submodules."
It's definitely an unreasonable chunk in Rechart's footprint, with relatively small benefit. Modern JS doesn't really need it, and although I saw the individual imports, it's notoriously hard to slim down the Lodash dependency because of its centralized architecture.
I've checked the imports, and I found not too many things, mostly isFunction and a few others, which are easy to replace with an ad-hoc implementation. First I'll try to replace them with a pnpm alias as a quick solution to see if my use case works.
I wouldn't dare venturing into a PR, because I can't check for all the use cases, but I'll let you guys know how it went for me.
Beta Was this translation helpful? Give feedback.
All reactions