You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re currently evaluating whether to remove lodash from our library, as discussed in this pull request.
The reasoning for moving away from lodash is understandable—it reduces dependencies and streamlines the library. However, one concern is that if the host app is already using lodash, removing it from the library may result in duplicating similar utility functions.
We want your input!
We’re considering three possible approaches, each with their own trade-offs:
1️⃣ Fully Remove lodash and Implement Utilities Internally
Eliminates security risks from third-party libraries.
Encourages the use of modern JavaScript methods.
Cons:
Some lodash functions are highly optimized and hard to replicate efficiently.
Requires maintaining and testing custom utilities.
If the host app already uses lodash, this could lead to redundant code.
2️⃣ Keep lodash for Consistency
Pros:
No breaking changes → everything continues working as is.
lodash is a well-tested, reliable library.
Prevents duplicate implementations for host apps that already rely on lodash.
Cons:
Adds an external dependency, increasing bundle size.
lodash usage is declining as modern JavaScript provides native alternatives.
Could pose security risks if lodash introduces vulnerabilities.
3️⃣ Provide an Interface for Custom Utility Injection
Pros:
Flexibility: Developers can inject lodash, custom utility libraries, or native functions.
Reduces unnecessary duplication for projects that already use lodash.
A middle-ground solution that accommodates different use cases.
Cons:
More complexity: Requires designing and maintaining an API for injecting custom utilities.
Potential inconsistencies if different users provide different implementations.
Higher learning curve for new adopters.
📊 What do you think? Vote below!
🔘 Option 1: Remove lodash entirely and implement utilities internally.
🔘 Option 2: Keep lodash to maintain consistency.
🔘 Option 3: Provide an interface for injecting custom utility functions.
💬 Have additional thoughts or concerns? Drop a comment below and let us know! Your feedback is invaluable in helping us make the best decision for the community.
Thanks for participating! 🚀
What do you think? Which option would you prefer?
Remove lodash entirely and implement utilities internally.
0%
Keep lodash to maintain consistency.
100%
Provide an interface for injecting custom utility functions.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hey everyone! 👋
We’re currently evaluating whether to remove lodash from our library, as discussed in this pull request.
The reasoning for moving away from lodash is understandable—it reduces dependencies and streamlines the library. However, one concern is that if the host app is already using lodash, removing it from the library may result in duplicating similar utility functions.
We want your input!
We’re considering three possible approaches, each with their own trade-offs:
1️⃣ Fully Remove lodash and Implement Utilities Internally
Pros:
Cons:
2️⃣ Keep lodash for Consistency
Pros:
Cons:
3️⃣ Provide an Interface for Custom Utility Injection
Pros:
Cons:
📊 What do you think? Vote below!
🔘 Option 1: Remove lodash entirely and implement utilities internally.
🔘 Option 2: Keep lodash to maintain consistency.
🔘 Option 3: Provide an interface for injecting custom utility functions.
💬 Have additional thoughts or concerns? Drop a comment below and let us know! Your feedback is invaluable in helping us make the best decision for the community.
Thanks for participating! 🚀
2 votes ·
Beta Was this translation helpful? Give feedback.
All reactions