И самый главный вопрос - нахрена класть ключом объект?

Хранить доп инфу об объекте, которая не является частью контракта объекта, но нужна, например, для его персистенса

Реальный кейс какой? С учетом что тебе тогда ещё и ссылку на него отдельно нужно хранить чтобы достать

Значение поля version при optimistic lock

Хранить версию в строке как ключ? Хранить объект, где значение другой объект в одном поле версия, в другом собственно бизнес объект? Сделать массив в котором тоже самое что во втором пункте? Сделать многомерный массив в котором первый элемент версия, второй сам объект?

Да как хочешь

Я понимаю, что как хочу. Я не понимаю зачем это нужно в принципе, я ни разу не видел использование Map в OpenSource проектах, которое нельзя было бы сделать в несколько раз проще

HashMap не видел как используют? Возможно ты смотрел на откровенную хуету

В HashMap ключом является массив. А я спрашиваю нахрена класть ОБЪЕКТ, тем более литерал как в примере. И да, про внутренности объектов и массивов в JS речи не идет. Я спрашиваю конкретно зачем делать const obj = {} и класть его как ключ? К HashMap это не имеет никакого отношения

Это структура данных. Чаще используется, когда необходима какая-то коллекция, с неупорядоченным набором элементов. Например у тебя есть поле, которое можно фильтровать и ты передаешь объект, с метаинформацией, а map отдает тебе значение. Да и не стоит забывать, что вокруг структуры есть интерфейс, который позволяет с этой структурой взаимодействовать. Ты конечно можешь это всё сам написать, но зачем?

Вот твой пример с объектом в объекте. Возьмем патерн репозиторий. Должен отдать нам бизнес сущность. В твоем случае он отдаст не бизнес сущность, а еще какой-то объект-обертку, который вне репозитория никакого смысла не имеет. А при создании бизнес сущности перед добавлением ее в репу, ее тоже оборачивать в этот объект? Получается размазывание обязанностей репозитория

Некорректная формулировка: ключом является хэш, а то, что сама структура может быть построена на массивах, уже детали реализации Но меня больше заинтересовала фраза про map, open source, и в несколько раз проще Можешь пояснить?

Ну то что я встречал, выглядит примерно так const obj = {a: 1, b: 2, c: 3} const m = new Map() m.set(obj, 123) // дальше где-то в коде for (let o of m.keys()) { if (o.a > 0) console.log(o.get(obj)) } Но ничего не мешало сделать так const arr = [{a: 1, b: 2, c: 3, value: 123}] arr.forEach(el => { if (el.a > 0) console.log(el.value) })

value может не относится к объекту. Вот пример с version и репами выше описал

value даже в мапе относится к ключу-объекту Ключ и значение относятся друг к другу в используемом контексте Правильно ли я понял твой пример: Задача: отдать бизнес-сущность и метаинформацию о ней. Мое решение: сделать объект обертку, но тогда при создании сущности нужно тоже заворачивать его в эту обертку (зачем правда я не понял, но это детали) Твое решение: сделать Мап обертку. И тогда при создании сущности нужно будет заворачивать в тот же мап.

Задача - отдать бизнес сущность. Мета должна остаться в репе

return buisnessEntity?

Ну да

Зачем Map?

Мне кажется суть этого вопроса в том, что всегда можно обойтись без объекта-ключа. И есть ли кейс, где без этого 100% не обойтись?