Егор Тельнов

Рекурсия есть:

const getLastDeepestElement = function(el) {
  return this(el, 0)[0];
}.bind(function get(el, level) {
  return [...el.children].reduce((p, c) => (
    c = get(c, -~level),
    p[1] > c[1] ? p : c
  ), [ el, level ]);
});

Рекурсии нет:

function getLastDeepestElement(el) {
  let result = [ el, 0 ];

  for (const stack = [ result ]; stack.length;) {
    const n = stack.pop();
    result = n[1] > result[1] ? n : result;
    stack.push(...Array.from(n[0].children, m => [ m, n[1] + 1 ]));
  }

  return result[0];
}

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

Рекурсия есть:

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

Рекурсии нет:

const getDeepestLastElement = el => Array
  .from(el.querySelectorAll('*'))
  .pop() || el;

// или

function getDeepestLastElement(el) {
  for (let c; (c = el.children).length; el = c[~-c.length]) ;
  return 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>