Алексей Уколов

Я бы посоветовал оставить начальный вариант, т.к. если сделаете banchmark'и - вы увидите, что он будет быстрее вашей реализации.
Т.к. в начальной реализации нет доп. вызова функции, а в вашей есть getRulesResult.
Чтобы вызвать функцию - нужно положить значения в стек, а по завершению извлечь.
За счёт этого ваша реализация будет работать медленнее.
Но это замечание справедливо только для функций, скорость выполнения которых критична, как сортировка например.

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

Но и визуально первый вариант понятнее.
Оцениваю просто по времени, которое нужно затратить на то, чтобы понять как работает начальная реализация и ваша, на начальную ушло меньше времени.

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

Но вы однозначно на верном пути, принятые решения и подход мне нравятся, просто у вас не совсем удачная задача для рефакторинга выбрана, решение изначально хорошее )

Обычно, код, который нужно рефакторить выглядит во много раз непонятнее, это может быть простыня на несколько экранов монитора :)), а когда в такой простыне еще и цикломатическая сложность огромная (вложенность if'ов и for'ов большая) - такой код вообще очень трудно понять :)
Вот тут самое то для рефакторинга.

Есть события: click, change, input и т.д.
Привязка обработчика соответствующего события с использованием атрибута тэга осуществляется с приставкой on:

<select id="selectTheme" onchange="alert('Theme changed')">
</select>

Но в тоже время, привязка обработчика события с использованием addEventListener не требует указания on, берется само название события и с названием атрибута не нужно путать:

sel.addEventListener('change', (event) => {
    	alert('Theme changed');
    })

Верстка делается сразу в React компонентах ? Или вначале делается классическая верстка, а потом переносится в React?

Как Вам удобнее.
Можно заказать вёрстку на аутсорсе, а потом перевести на реакт. А можно сразу верстать на реакт компонентах.

Если я делаю какой-то сложный с точки зрения вёрстки компонента - я сначала просто верстаю его на чистом HTML, потом декомпозирую на подкомпоненты, если это имеет место быть, а потом накидываю реактивность и логику условного рендеринга. Я считаю, так компонент получается качественнее, с точки зрения вёрстки.

если сайт на React, там все должно быть на React или допускается сделать некоторые элементы на нативном Js

Реакт по своей природе - библиотека, которая может быть добавлена на любой сайт.
Что означает, что у вас может быть 90% статичной вёрстки и 10% на реакте(какие то виджиты, отдельные блоки или сложные формы).
И наоборот.
Как и 100% на реакте.

Да нету их особо, SQlite да вроде бы Firebird умеют быть встроенными-переносными без лютого бэкграунда.
На мой взгляд у вас либо неправильная постановка задачи либо непраильная организация данных, либо тупо лень-матушка делать данные удобными для быстрого поиска.
Кроме того есть прям-прям специальные решения для быстрого полнотекстового поиска по текстам, вряд ли среди них есть встраиваемые легковесные решения, ElasticSearch тот же.

Создаешь политику: https://laravel.com/docs/8.x/authorization#creatin...
описываешь логику (ну, чтобы там автор, админ и назначенные могли видеть, автор и админ - менять, или любую свою), и в контроллер добавляешь регистрацию этой политики в конструктор: https://laravel.com/docs/8.x/authorization#authori...

NCurses Disk Usage

sudo apt install ncdu

Именно две или первая нужна постольку поскольку нужно поле mytarget из нее?

Если важен только последний запрос, можно сделать так

SELECT result 
FROM mydata 
WHERE id < '127' AND mytarget = (SELECT mytarget FROM mydata WHERE id = '127')
ORDER BY id DESC 
LIMIT 1

Если же нужны именно обе строки, тогда UNION

SELECT result, mytarget 
FROM mydata 
WHERE id = '127'

UNION 

SELECT result, mytarget 
FROM mydata 
WHERE id < '127' AND mytarget = (SELECT mytarget FROM mydata WHERE id = '127')
ORDER BY id DESC 
LIMIT 1

Насчет быстрее, сказать трудно; но обычно два запроса выполняются дольше одного, пусть и сложного.

В Laravel есть хелпер route. Чтобы его использовать надо дать маршруту имя. https://laravel.com/docs/8.x/helpers#method-route Вот посмотрите.

Делать наоборот - при логине пользователя запрашивать AD по LDAP - если разрешает логин - логинить.

Там можно бегло оценить какой форк стоит выбрать.

Либо как вариант автоматизировать это дело с помощью парсера реп (при условии что это оправданно)

За свою жизнь мне довелось поработать в веб-разработке, автоматизации газопроводов, бухгалтерии, автоматизации бизнеса и даже дизайнером рекламы и журналистом. И останавливаться пробуя новое пока не собираюсь) При этом образование у меня - радиотехника.

Образование не ограничивает круг возможных профессий, а жизнь иногда складывается так, что приходится заниматься совершенно неожиданными вещами. Выбирайте ту специальность, которая ближе Вам в данный момент, интернет здесь вряд ли подскажет оптимальный выбор, тем более что у каждого здесь свой собственный путь и своя правда - кто-то оканчивает ВУЗ и всю жизнь работает по специальности, а кто-то ищет себя в самых неожиданных областях.

Тайпскрипт правильно ругается потому что таргет события не обязательно должен быть дом элементом. События могут так же порождаться, например XHR запросами.

Я бы на вашем месте сделал так называемую type guard функцию, в которой убеждался бы что таргет действительно элемент дом. Все элементы дом наследуются от объекта HTMLElement. Это можно использовать для проверки:

const isHtmlElement = (v: any): v is HTMLElement => v instanceof HTMLElement;

далее мы можем использовать эту функцию для проверки нашего таргета:

const eventHandler = (e: Event) => {
  if (!isHtmlElement(e.target)) {
    return;
  }
  // Вот здесь мы можем смело работать с таргетом как с ДОМ Элементом
  e.target.classList.toggle('active');
}

УПД

Еще информация к размышлению.

Финальный код, сгенерированный тайпскриптом, не содержит информации о типах. В рантайме нельзя узнать тип интерфейса, выполнив, например `peremennaya instanceof VashInterfeis`. Но всегда можно создать type guard функию, которая будет определять что объект именно нужного типа по каким-то косвенным признакам (например по наличию определённых полей в объекте). Так как код guard функции невозможно провертить статическим анализватором, тайпскрипт не может гарантировать того что ваша guard фунция верна и не пропускает всё подряд. Поэтому, хорошим тоном является писать такой код, который не нуждается в подобных проверках. Это возможно. Код при таком подходе становится стройнее и легче для осмысления.

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

в общем: все зависит, универсального ответа нет.

ну и стоит отдельно определиться, что подразумевается под сырыми запросами: квери-билдер или прямой доступ к базе. последнее я практически не использую.