Антон Спирин

Как вариант
jsfiddle.net/Symphony/nptcmL0e

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

2) ни о чем.
3) при нынешних объемах дисков и размере этих самых компиляторов говорить об этом не имеет смысла.
5) инклюды в препроцессоре дают возможность разбить весь css на отдельные небольшие и логичные файлы, с которыми проще работать, и на выходе сольют их в один файл, а не n разных в случае link rel. это хорошо в плане client-side optimization, хотя для хомяков и не критично.

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

1) Препроцессоры позволяют вводить переменные и миксины. Но ведь в CSS можно просто создать свойство

Ну, одно дело добавлять к селектору в css, другое дело захламлять html, а там уже сложнее будет менять класс (т.к. html может генерироваться как угодно).

2) Валидность CSS.

Ай, да на это пофиг, есть и другие средства для проверки.

3) Компилятор из препроцессорного языка в CSS.

Ну там легкий скриптик выполняется в сборщике автоматом (на webpack, gulp, parcel и.т.д.). Особо ничего не нагружает, на ssd при сохранении файла scss меньше чем за секунду компилируется css.

4) Удобочитаемость кода, и простой поиск,

А тут как раз наоборот. Искать по scss гораздо сложнее, т.к. нельзя врубить поиск по целому селектору. Но если стоит Sourcemap (грубо говоря, который учит инструменты разработчика хрома понимать scss), то уже можно спокойно смотреть в хроме номер строки, название классов и.т.д.

5) Возможность инклюда (include) в препроцессорах.

Оптимизация. Пока не пришел http 2, все ресурсы желательно склеивать, скрипты, стили и даже картинки в спрайты. Один файл грузится быстрее чем несколько, т.к. достаточно одного http запроса. С приходом http2 будет пофиг.

6) Вложенность свойств.

Ну вот смотри, есть у меня такая менюшка

<nav class="menu">
   <ul class="menu__list">
      <li class="menu__item menu__item_active">
         <a href="#" class="menu__link">Menu 1</a>
      </li>
      <li class="menu__item">
         <a href="#" class="menu__link">Menu 2</a>
      </li>
   </ul>
</div>

В css мой код на БЭМ будет выглядеть вот так

.menu {

}
   .menu__list { }
   .menu__item { }
      .menu__item_active { }
      .menu__item:hover { }
   .menu__link { }

а на scss вот так

.menu {
   &__list { }
   &__item { 
      &:hover { }
      &_active { }
   }
   &__link { }
}

проще и лаконичнее. Но этой слишком простйо пример. Там еще можно добавлять медиазапросы, дополнительные модификаторы.

7) На хабре видел в комментариях обсуждение, мол можно даже задавать в препроцессорах - какие браузеры поддерживать. Ахтунг! А зачем писать такие стили, которые не будут работать в старых браузерах?

Это больше для вендорных префиксов и всяких полифилов. Это по моему в PostCSS юзается через doiuse, точно не знаю, в scss с таким не сталкивался. Обычно пофиг на старые ie.

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

В маленьких проектах чаще да, если нет готового сборщика, то удобнее сразу писать прототип на css. Но сейчас любой фрейморк в пару команд позволяет добавить поддержку scss.

Это удобная штука, не нужно ее бояться, не нужно бояться webpack, фреймворки, но и не нужно фанатеть, это просто инструменты.

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

А доку почитать? https://reactjs.org/docs/forms.html

Да так же, как у вас есть сейчас со встроенным скриптом - указываете type="text/babel" вашему отдельному файлу при подключении.

А вообще, вам стоит загуглить: "webpack", "create-react-app".

glebvvs,

state.push(action.payload);
    return state;

замени на:

return [...state, action.payload];

https://developer.mozilla.org/en-US/docs/Web/API/E...

name - специальный аттрибут. Куда попало нельзя его ставить.

Потому что есть правило, имеющее больший приоритет. Погуглите "специфичность селекторов css".

конечно, так это обычно и делают.

только делают это вот так

data: {
              ...state.data,
              [action.payload.type]: action.payload.value,
            }

В ESlint есть для этого правило, и нередко в конифгах такое запрещают, причем в пределах всего файла (будь то импорты и локальные переменные)

componentDidUpdate -> prevProps vs props

Sketch, Figma, Lunacy

Что, уже появились люди, которые не помнят изначального домена сайта? habrahabr.ru
Отсюда и слова эти с с буквой а.
И грамматика здесь не при чем.

Дополню. В речи название сайта часто сокращалось до "хабра" - на хабре, с хабры и т.п. В этом контексте "хабражитель" — вполне правильное написание.

А вы знатный велосипедист.

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

axios

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

react stateful components

- фактически view совмещен с контроллером, из-за этого уже сейчас сложно работать с файлами контроллеров - они разрастаются и содержат много html - кода. Кроме того, они завязаны на глобальные данные, про которые я уже писал и получается, что ни о каком модульном подходе не приходится говорить. Как от этого избавиться при текущей архитектуре не знаю.

react-redux, react decomposition

- практически все данные и весь код приложения доступен и открыт через консоль браузера (можете сами посмотреть). В том числе видна вся структура приложения - можете сами посмотреть. Можно ли что-то с этим сделать я не знаю.

webpack, etc...

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

react error boundaries

- проблема с навигацией и индексацией из-за AJAX (сейчас вроде как уже понял, что нужно использовать pushState)

react-router, ssr

- что делать и нужно ли что-то делать для тех, кто не использует JS. Например те же рекомендации по SEO для AJAX говорят что для всех динамических страниц нужно иметь статический snapshot. Как его реализовать - чтобы это было "дешево (просто) и сердито (не криво)" я не знаю.

ssr

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

Таким образом проще переписать приложение с использованием какого нибудь современного стэка (react например)