NR
Не нужно хранить индекс в ключах
Size: a a a
2020 July 10
NR
Как вам уже выше сказали - вы сами создали себе проблему на пустом месте
TG
ну конечно, со стороны все кажется простым. кейс не такой каким кажется с вашей точки зрения
TG
Как вам уже выше сказали - вы сами создали себе проблему на пустом месте
структура с которой нужно работать. может быть любой вложенности. в ней могут быть как массивы так и объекты.
нужно всю эту структуру перенести в формат хэш объекта что бы не приходилось делать рекурсивный обход, когда нужен доступ к каждому из полей. единственный способ сделать это без потери адресации — хранить в качестве ключа путь.
нужно всю эту структуру перенести в формат хэш объекта что бы не приходилось делать рекурсивный обход, когда нужен доступ к каждому из полей. единственный способ сделать это без потери адресации — хранить в качестве ключа путь.
TG
так бы будем знать что arr[0], это путь к 1-вому элменту вложенного массива.
TG
arr[0].someField.arr[0] — еще один объект и мы знаем где он находиться благодаря ключу
TG
если не хранить индекс невозможно будет понять кому он принадлежит и на каком уровне вложенности находиться.
TG
по этому все так просто как выше писали не получиться сделать.
NR
А хехмапа вам зачем тогда? Если вы знаете путь, то можно напрямую обратиться к изначальной структуре по нему
TG
А хехмапа вам зачем тогда? Если вы знаете путь, то можно напрямую обратиться к изначальной структуре по нему
я же говорю. если мне нужно пройти по всем полям, то я не знаю путь каждого поля. но вот в хешмапе такого вида, я могу это сделать без всяких рекурсий.
TG
а если знаю путь, то да, без проблем. и так и так могу попасть к нему.
TG
но необходимость эту nested структуру делать инлайновой в том, что бы иметь возможность, быстрого прохода по всем полям без рекурсии.
TG
и тут проблема. проход без рекурсии мы имеем. а вот удалить поле которое находиться в массиве проблематично
TG
проделывать операции с каждым полем во первых быстро, во вторых легко без всяких сложных алгоритмов. по этому необходимость в такой структуре весьма оправдана.
NR
я же говорю. если мне нужно пройти по всем полям, то я не знаю путь каждого поля. но вот в хешмапе такого вида, я могу это сделать без всяких рекурсий.
Это типичная задача для нормализованных данных
TG
Это типичная задача для нормализованных данных
я вот выше спросил что обычно имеется вид под нормализованными данными
NR
я вот выше спросил что обычно имеется вид под нормализованными данными
Плоский объект с ид в виде ключей
TG
Плоский объект с ид в виде ключей
если у нас массив. то да, все легко. мы превращаем его в плоский объект в виде ключей. где каждый ключ ID. это понятно и просто.
но тут как я писал выше, вложенность может быть любой и в ней есть как массивы так и объекты. и подмассивы и подъобекты. и массивы массивов.
но тут как я писал выше, вложенность может быть любой и в ней есть как массивы так и объекты. и подмассивы и подъобекты. и массивы массивов.
TG
если мы сделали из этой структуры хеш объект в виде
"путь: значение",
то мы без рекурсии можем пройти по всем полям очень быстро.
"путь: значение",
то мы без рекурсии можем пройти по всем полям очень быстро.
TG
const obj = {
a: {
b: [{target: '0'}, {target: '1'}]
c: {'target: '2''},
}
};
вам нужно часто проходить по всем полям на последнем уровне вложенности. самое глубокое значение всегда одного вида {target: ''}.но он может лежать в любой вложенности или в массивах.
что бы решить эту проблему я перевел всю эту структуру в такой хешобъект:
{
a.b[0]: {}
a.b[1]: {}
a.c: {}
}
теперь без рекурсии я могу бегать по полям сколько хочу. но вот удалить уже проблема.