ладно, пойдет. А теперь расскажите про принципы SOLID. *ба-дум-тс*.

Я бы ответил в общих чертах на вопрос "зачем нужны фреймворки".
- найм. Люди легче идут на то что знают и на то что будет востребованно когда они уволятся.
- трансляция знаний.  (документация, stackoverflow etc). Вашему велосипеду всех учить заново
- готовые решения (тянуть мусор с нпма а не писать самому :)). Опять же, проблемы с производительностью можно самому решать :)

Разумеется при выборе есть технические детали, в зависимости от того как фреймворк ложится на вашу доменную и техническую специфику. Это уже "зачем нам фреймворк А а не фреймворк В"

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

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

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

Производительность в огромном количестве проектов просто не важна

Ну да, это конкретное приложение общего правила на вполне конкретную специфику

В общем этот вопрос он немножко показывает понимание big picture а не только мелких технических деталей.
Есть такой сорт разработчиков которые любят додалбываться до каких-то конкретных мелких деталей даже в случаях когда они совершенно, нефига не важны для конечного продукта. Это может быть заточка производительности, могут быть абстрактные фабрики абстрактных фабрик, безопасность, чистота кода etc... Многие кстати этот этап проходят будучи условными "мидлами".

Такой сорт разработчиков хорошо применим только в очень специфических проектах, когда их любимые детали - действительно важны для продукта. А в других может быть даже вреден. Но большинство типичных метрик (опыт работы, гитхаб, литкод, типичные вопросы etc) у них в порядке. Открытые вопросы такого рода это какой-никакой индикатор именно того насколько вам человек достался... профессиональный что ли. Именно с точки зрения применимости в промышленной разработке а не технических навыков.

я это вижу так по крайней мере

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

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

А как вы различить тип на массив из 3 элементов (тюпл) и массив из 3 строк?

Собственно тс тоже не может

Ребят как правильно передать функцию через  props  в другую компоненту, я сделал так, но приходит не функция а  undefined

для значения [['foo', 'bar', 'baz']] isNested вернет true что собственно тс и указывает

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

для значения [['foo', 'bar', 'baz']] isNested вернет true что собственно тс и указывает

Так я не передаю такое значение в isNested, у меня на 15й строке итерация происходит, в isNested попадает в виде аргумента
либо ['test2', '=', '2']
либо  [['test2', '=', '2'], 'and', ['test3', '=', '3']].
И вот я пытаюсь определить, что из этого кортеж, а что Foo

Pipy

у вас в типах знание что "первый элемент строка" - не описано

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