The modern, community-first TypeScript toolkit with all of the fast, readable, and minimal utility functions you need. Type-safe, dependency-free, tree-shakeable, fully tested.
We are investigating the ways we could safely migrate from lodash-es and use modern library with better state, support and code quality.
The only blocker we have now is the difference between set() behavior in lodash and radashi
Let's say we have object with server errors after validation:
const errors = {
email: 'Should include @',
entries: [{ date: 'Should be date in YYYY-MM-DD' }]
}
then i want to strip error after user provided correct date via set(errors, 'entries[0].date', undefined)
Lodash version sets value as undefined, while radashi makes early return, leaving the value untouched
I suggest to make parity between behavior in lodash and radashi in that particular case. If undefinedcheck had been designed to just check if 3rd argument was passed, we can check arguments length instead.
I also understand this is going to be a breaking change, so we this may happen in 13.0
We are investigating the ways we could safely migrate from lodash-es and use modern library with better state, support and code quality.
The only blocker we have now is the difference between set() behavior in lodash and radashi
Let's say we have object with server errors after validation:
then i want to strip error after user provided correct date via
set(errors, 'entries[0].date', undefined)
Lodash version sets value as undefined, while radashi makes early return, leaving the value untouched
I suggest to make parity between behavior in lodash and radashi in that particular case. If
undefined
check had been designed to just check if 3rd argument was passed, we can check arguments length instead.I also understand this is going to be a breaking change, so we this may happen in 13.0