Егор Тельнов

Рекурсия. Обходим дочерние элементы, смотрим уровень вложенности:

const walk = (el, level = 0) =>
  [...el.children].reduce((p, c) => {
    c = walk(c, level + 1);
    return p.level > c.level ? p : c;
  }, { el, level });

const getLastDeepestElement = root => walk(root).el;

Если же под последним самым вложенным подразумевается элемент, получаемый постоянным выбором последнего вложенного элемента, то тогда так:

const getDeepestLastElement = el =>
  el.lastElementChild
    ? getDeepestLastElement(el.lastElementChild)
    : el;

// или, без рекурсии
const getDeepestLastElement = el => Array
  .from(el.querySelectorAll('*'))
  .pop() || el;

Оператор сравнения в plpgsql такой же как в SQL. is null для проверки является ли значение null и = для равенства.

Для изменения вставляемой строки вы должны модифицировать переменную new, а не пытаться уйти в бесконечную рекурсию выполняя аналогичную вызвавшему триггер операцию.

Если коротко исторически так сложилось.

В который раз встречаю человека который упорно не желает пользоваться STL. При том это какое то иррациональное нежелание.

А теперь длинно.

Хочешь плохому научу?
Выделяй память malloc'ом, а когда надо изменить размер "массива", пользуйся realloc'ом. Можешь так же как в встроенном массиве пользоваться [] для обращения к элементам массива.

Дальше напиши какую нибудь серьезную программу тыщ хотя бы на 20 строк. И в один прекрасный день узнай, что она крашится в самом неожиданном месте, хотя раньше все работало. Далее две бессонных недели, с красными глазами проведи с отладчиком в поисках неуловимого бага. После чего совершенно случайно найди место где вылазишь за пределы массива или обращаешься к неинициализированной памяти. Вот после этого станет понятно, что так жить нельзя. И вот все это безобразие размазанное по всему коду надо собрать в одном месте. И все проверки и инициализацию делать там. А где это в одном месте? Правильно написать собственный класс, там и конструктор есть для инициализации по умолчанию и [] перегрузить можно, что бы всякие проверки делать и деструктор, что бы за собой прибрать. А потом тебе захочется, что бы твой класс работал с разными типами данных и ты перепишешь его на шаблонах.

А теперь загляни в стандартную библиотеку. Поздравляю все это уже давно сделали за вас гораздо лучше и со множеством приятных плюшек. Тысячи программистов прошли этот путь за более чем 40 лет. Так зачем, зачем проходить этот путь еще раз? У вас, что есть запасная жизнь? Берите и пользуйтесь готовым. C++ имеет тысячи подходящих инструментов. Пользуйтесь ими. Так нет каждый новый адепт хватает кирку и лопату и бежит строить днепрогэс. Не надо построили уже до вас. Вы в стандартной библиотеки поищите оно там есть.

да

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

Всю логику всегда стоит выносить из компонентов, так как они должны отображать только состояние и данные. Посмотри react-redux. Для асинхронных запросов понадобится thunk как middleware. В инете полно гайдов.

Посмотри в сторону React Hooks и Context API
https://medium.com/@alexboots/using-react-context-...

Реализация с помощью экспресса:

var app = express();
app.use(express.static(__dirname + '/dist/css'));

Атрибут target

<a target="_parent" href="http://example.com">link</a>