Вообще если получается - лучше разбивать запросы через WITH и не писать SELECT с SELECT'a c SELECT'a ...

Т.е. это вполне норм практика

WITH a_not_included AS (
 SELECT b_id, a_id FROM A, A2B, B WHERE 
 A2B.b_id = B.id AND
 A2B.a_id != A.id
),  a_included AS (SELECT b_id, a_id FROM A, A2B, B WHERE
  A2B.b_id = B.id AND
  A2B.a_id = A.id
)

SELECT b_id, array_agg(a_not_included.a_id), array_agg(a_included) FROM a_not_included, a_included WHERE a_included.b_id = a_not_included.b_id GROUP BY b_id;

Ну запрос не сильно сложный по идее, делать WITH выглядит пушкой против воообьев, но чет соптимизировать выполнение через exists, чтобы избежать перемножения похоже была не лучшая идея, проще уж прикрыться groupby

ребят, вопрос по обходу дерева, мне кажется я чего-то не замечаю или решаю не ту проблему

вот есть у меня дерево на входе, скажем, такого вида:

root
  - blockquote
    - paragraph
      - text

Выход у меня это либо

- транслировать каждую ноду в вызов моего апи
- делать POJO, т.е. схлопывать ноды в объекты

Только что стёр уже третью реализацию, которая не годится… Проблемы всегда возникают в месте, когда надо ноды смешивать.
Вот на примере выше, у меня должен получится один объект из всех тех нод: если text, то это обычный текст, если paragraph, то подмешать в текст соседние ноды, если blockquote, добавить > и изменить стиль отображения. По итогу это должны быть объекты, которые описывают геометрию фигуры в терминале, которая уже потом отрендерится.

И вот собственно вопрос, сталкивался ли кто-то с таким обходом дерева? Выглядит как простая задача, бери себе визитор, на каждый визит возвращай объект и подмешивай в вышестоящий, но вот что-то оно не клеится

UPD: а ещё это фиг опишешь на типах, потому что у тебя каждый визитор возвращает вообще что-то своё

root
  - blockquote
    - paragraph
      - text

напомни, что тьі хочешь сделать потом с деревом?
тьі можешь посмотреть как сделано в xml парсерах типа html, там та же структура

мне нужно из него крафтить вот такие объекты

{
  name: ‘bla-lba’,
  type: ‘Text’,
  options: { // based on node }
}

вот только вот эти options надо менять по ходу обхода

тот визитор что они дают, он в ширину идёт, что мне совсем не подходит
поэтому визитор тоже можно самому делать, у меня только дерево

{
  name: ‘bla-lba’,
  type: ‘Text’,
  options: { // based on node }
}

мне кажется сначало надо превратить в дерево нод-обьектов, а потом отдельно рендерер

типа не визитор делать, а трансформ

получается у тебя не только вглубь обход, а оба и родитель знает что за ребенок и ребенок знает кто родитель

как минимум проще для понимания будет

ну вроде да, вот если брать классический в глубину, то

я дойду до текста - верну

{
  name: ‘bla’,
  type: ‘Text’,
  options: { text: node.value }
}

потом начну вверх подниматься, paragraph получит этот объект и т.к. это compound, у него может быть несколько таких, мне надо будет их мержить в один объект и возвращать и т.д.

блин, мне кажется у меня сейчас уточка случилась и я вроде понял чего не хватало

но это не точно

ну вот кстати, layout это вообще отдельная тема
я скорее всего не буду делать полноценный layout в kittik 🙂
это муторная и сложная тема

скорее всего, я солью layout и парсер в одну концепцию, у парсера будет свой дефолтный layout которому можно будет менять темы (это максимум)

да я так и заметил)

Пиппл, я тут один эксперимент провел, сделав хук на базе useState специально для массивов, который возвращает [array, arrayRef]. array - это, собственно, массив, arrayRef - это такой себе "магический" объект, в котором можно вызывать нативные методы массива: push, splice... При этом сам массив остаётся immutable. ХЗ, если в этом смысл, было прикольно попробовать такое. https://gist.github.com/finom/1d0da52add2db4c50af43eed6add4d92

const [array, arrayRef] = useArrayState([]);
arrayRef.push(foo); // triggers component to re-render and makes 'array' to get a new value [...array, foo]

это что-то между immutable и observable. Выглядит как второе, работает как первое.