In which case I'd put it in a lib, but how would this be named ?
I'd also make a second implementation that would enforce ID uniqueness and use Map to map IDs with indexes instead of running find : while the first implementation would be fine for static data, the second one would be more suitable for dynamic data.
Seems like a great idea.
I often find myself using objects when I'm building data (like a horrible CSV processor). It's easy to pull in a row of data, and potentially modify existing data (yeh, really horrible CSV).
But when it gets to processing the data (transformers and database), I prefer arrays.
A lot of it comes back to typescript, where Object.keys().forEach means the key isn't necessarily usable to access the item in the object (the whole, a key becomes a string, but an object can be keyed by string/number/symbol). .
So, whatever you come up with HAS to have first class Typescript support.
Fair enough, I can understand that.
I used to enjoy the flexibility that JS provides. And IDEs do a pretty good job of filling the holes!
My last project, I went all in on typescript. And I have caught so many more errors before even compiling.
It's like having tests. It gives a hell of a lot more confidence.
Some days I miss just slinging objects around, and just coercing types tho (without explicitly casting/converting... Object keys being a big one!)
I used to enjoy the flexibility that JS provides. And IDEs do a pretty good job of filling the holes!
Exactly.
My last project, I went all in on typescript. And I have caught so many more errors before even compiling.
It’s like having tests. It gives a hell of a lot more confidence.
I can understand that too. Although, IDEs also catch a lot of type-related errors in vanilla JS.