Владимир Проскурин

вопросов о выносе SubmitButton в отдельный компонент не возникает.

SubmitButton выносить в отдельный компонент не надо. В большинстве случаев хватает использования обычной кнопки вашего приложения.
<Button onClick={handleSubmit}>Submit</Button>

Чем руководствоваться при выборе, вынести ли «подкомпонент» react в компонент или поместить в функцию внутри компонента?

Компонент это сущность, если часть древа можно описать как сущность, то логичней ее вынести в компонент. Особенно если она будет в последствии переиспользована. Например:
ListItem, Preloader, Layout, Modal, Container, FormControl, etc.

Если часть древа описывается задачей(например renderRows, renderItem, etc) и ее надо меморизировать, или она используется под условным рендерингом и для отрисовки необходимы дополнительные вычисления, то ее часто логично вынести в отдельный рендер метод, не нагромождая кодовую базу дополнительными компонентами.
Колбеки паттерна render-props так же имеет смысл выносить в отдельные render-методы.

что вы читали/учили никому не интересно. всем интересно сможете ли вы решать их задачи.

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

Как по мне все довольно индивидуально, у меня опыт 1 год и 3 месяца.
Начинал практически с нуля.
Мои зарплаты по месяцам если интересно.
1й-3й месяц работы 10к рублей в месяц - знания нулевые, в основном учил основы
после 3 месяцев сменил работу, ибо устали меня учить и получалось так себе, решил уйти + это была удаленка, прибавляй все сопутсвтующие сложности
3й месяц - 1 год работы устроился в офис стажером, зп $200 - $800 (варировалась т.к. была почасовка и зп менялось в зависиомости от отработанных часов)
После года - новая работа, работаю с июля(уже 3 месяца) Зп в районе $2000.
Опять же уровень свой оцениваю - как низкий, серьезный буст по зарплате в моей ситуации происходит только при смене работы. В рамках одной работы больше чем на 1,5$ в час за раз не повышали.
Вот как-то так, отвечая на ваш вопрос, что сейчас что год назад я джун. Но за год я вырос значительно, но весь рост все равно в рамках джуна. Поэтому нужно учитывать какого джуна ищут и что хотят видеть. Вряд ли абсолютному новичку дадут сразу 80к рублей, думаю для этого все же нужно немного повариться за меньшую зп.

Во время вызова render, элементы еще не созданы и не добавлены в DOM, соответственно ref равен null. Вы можете получить ref после монтирования:

class B extends React.Component {
  componentDidMount() {
    console.log(this.props.anchorRef);
  }
}

В вашем случае правильней использовать useRef, так как в отличии от вызова createRef, он при перерисовках возвращает один и тот же объект. Вызов createRef, в свою очередь, каждый раз возвращает новый.

function A {
  const anchorRef = useRef<HTMLDivElement>(null);
  // ...
}

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

Алгоритмы не надо запоминать, их надо понимать. Если один раз понял, как работает сортировка Шелла или алгоритм Дейкстры, то уже никогда не перестанешь понимать. Это как умение ездить на велосипеде.

Давайте разберем все по строчкам, что Вы тут понаписали:

function toggleMe() {
  // я кажется начинаю понимать ОТ кого придумали typescript...
  var a = 0; // если логика подразумевает логический тип, зачем init-значение число?
  return function() {
    if(a = true) { // это условие всегда будет истинно, независимо от a, в a сохраним значение true
      a = false;
    } else if (a = false) { // в принципе тоже что и выше, но еще этот код не достижим
      a = true;
    }
    return a;
  }
}
var a = toggleMe(); // в a извлекли функцию с замыканием
var b = a(); // в b будет false
console.log(b);
console.log(b); // а второй лог что-то меняет? нет

Теперь давайте посмотрим, что произойдет, когда данный код попадет в современный движок JS:





P.S. возможно имелось в виду это:

function toggleMe() {
  var a = false;
  return function() {
    return a = !a;
  };
}

var b = toggleMe();
console.log(b());
console.log(b());

Итак,

какие конкретно стоит почитать

1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место.
Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

подсознательно я продолжаю выбирать именно "правильные" подходы,

Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

наследование — это реализовывается само собой.

Вот эта фраза явно даёт понять что у вас есть проблемы в дизайне. Наследование это весьма опасная штука, и делать его просто потому что показалось удобным, не задумываясь об LSP, контрактах и инвариантах.. Кхм.. Плохо.

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

Никогда не пользуйтесь гуглом, он только для профессионалов, легче же всегда задать вопрос тут.

Где взять простые макеты для практики верстки?
Где взять макеты для верстки?
Где взять PSD макеты с исходным кодом?
Где взять макеты?
Где взять макеты psd, сверстав которые можно показать в портфолио?
Где взять макет для тренировки верстки на Bootstrap?
Где взять дизайны (,psd) для практики верстки?
Где взять простые psd макеты по bootstrap сетке?
Где взять качественные макеты в .psd для практики?
Где взять бесплатные адаптивные psd макеты?
Где взять проектов под портфолио верстальщика?
Где взять полноценные макеты интернет магазинов (не лендинги)?
Где брать многостраничные PSD?
Где можно взять psd макеты для Wordpress?

Не получится у вас с помощью многопоточности задействовать несколько ядер.

А ошибка связана с тем, что метод map в первом параметре принимает ссылку на функцию, а не результат её выполнения.

Владимир Проскурин уже ответил вам, как следует адекватно сделать, но если Вы захотите немного псевдоэлементов и оставить структуру кода html, как есть, то переходите по ссылке)

https://codepen.io/anon/pen/dBKeaz

1. Почитайте про управляемые компоненты. Знаний, полученных из статьи, должно хватить чтобы собрать значения всех фильтров с состояние компонента.
2. Для параллельного запроса к массиву источников можно использовать Promise.all или поискать реализации Promise.settled. Почитайте это обсуждение, где обсуждается проблема отклоненного Promise. Результаты так-же пишите в state.
3. Почитайте про списки и ключи. Знаний, полученных из статьи, вам должно хватить, чтобы отрисовать полученные данные в виде списка.

Эти категории очень условны, соответственно и чёткой границы нет. Сеньор из одной компании может быть едва мидлом в другой, и наоборот. Определить уровень зрелости программиста может только другой программист, существенно превосходящий его опытом.