The point here was Map solves this purpose, i am not trying to showcase that Objects are inferior to Maps, but Maps are designed to solve some loopholes which were initially created, and Maps does it without looping over the keys
We need length of objects, it a simple clash between what you feel is ideal and what is real, ideal world !== real world. Why i wrote the problem is because multiple dev would have faced it, and its not wrong to do it with .entries or .keys, but if we have a data structure which does not allow you doing any of those stuffs and gives to the length in o(1) then why not use it in such condition ?
It was a point to consider, some devs already know it, but there can be problem if someone is not aware of the inherited methods, hence my point. Again Maps does not have this, its pretty safe to use was my answer to this.
I liked the way the spread works, i forgot about it, its a good point, how this this work if i want to delete nested keys ?
Now coming to your another solution for the example. Here we have no backend dependency. Backend will always give us array of objects to render as rows in the table.
The point here is what happens when you select a row or what happens when you click on select all on the header. You are using a array to maintain selected items which is correct no issues in small or moderate list.
My point over here is when re-rendering the list again, post select-all is clicked, every row while rendering will have to make a lookup to the selected list array, to know if we want to render a selected state or not. This is simply a O(n) lookup done by each row to either show or not show selected state.
Which is solved by either objects or Maps which is done in O(1)
Last but not the least, its just wonderful to have conversation on a topic, since i am trying to constantly learn myself, and learn from my mistakes. Its was a great conversation @lukeshiru
, i learnt a lot from our conversation.
Cheers!
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for commenting
The point here was Map solves this purpose, i am not trying to showcase that Objects are inferior to Maps, but Maps are designed to solve some loopholes which were initially created, and Maps does it without looping over the keys
We need length of objects, it a simple clash between what you feel is ideal and what is real, ideal world !== real world. Why i wrote the problem is because multiple dev would have faced it, and its not wrong to do it with
.entriesor.keys, but if we have a data structure which does not allow you doing any of those stuffs and gives to the length in o(1) then why not use it in such condition ?It was a point to consider, some devs already know it, but there can be problem if someone is not aware of the inherited methods, hence my point. Again Maps does not have this, its pretty safe to use was my answer to this.
I liked the way the spread works, i forgot about it, its a good point, how this this work if i want to delete nested keys ?
Now coming to your another solution for the example. Here we have no backend dependency. Backend will always give us
array of objectsto render as rows in the table.The point here is what happens when you select a row or what happens when you click on select all on the header. You are using a array to maintain selected items which is correct no issues in small or moderate list.
My point over here is when re-rendering the list again, post select-all is clicked, every row while rendering will have to make a lookup to the
selected list array, to know if we want to render a selected state or not. This is simply a O(n) lookup done by each row to either show or not show selected state.Which is solved by either objects or Maps which is done in O(1)
Last but not the least, its just wonderful to have conversation on a topic, since i am trying to constantly learn myself, and learn from my mistakes. Its was a great conversation @lukeshiru , i learnt a lot from our conversation.
Cheers!