Реакт очень популярен. Из-за этого многие новички используют его неправильно, не понимая, какую задачу он решает.

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

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

Не пишите бизнес-логику в Реакт-компонентах. Логика приложения должна быть скрыта в отдельном модуле, который предоставляет наружу простой и декларативный API, которым можно пользоваться даже через консоль, без UI.

Не используйте Реакт для роутинга. React Router это очень популярная библиотека с нескольким десятком тысяч звёзд на Гитхабе, но серьёзно, она провоцирует разработчиков творить ужасные вещи. Она заставит вас нарушить предыдущий пункт и писать бизнес-логику в компонентах. Она заставит вас относиться к URL как к ещё одному источнику состояния приложения. Она заставит вас смешать вёрстку и настройки роутера (а в четвёртой версии появляется возможность раскидать настройки роутера вообще по всему приложению). Роутинг быть скрыт в отдельном модуле. URL должен зависеть от состояния приложения, а не наоборот. Это значит, что URL должен меняться автоматически при изменении состояния приложения. Обращаться к URL для чтения каких-то данных нельзя вообще никогда, кроме момента инициализации приложения (в момент инициализации можно использовать данные из URL для задания исходного состояния приложения).

Не используйте Реакт для общения с сервером. Серьёзно, есть компоненты вроде <Fetch url='...' /> — пожалуйста, не делайте так. За общение с сервером должен отвечать отдельный модуль, скрывающий детали реализации и предоставляющий абстрактный API вроде articles.get({ id: 1 }).then((article) => {}).

Хороший пример реализации роутинга (пример для редакс-приложений, но принцип общий) — https://github.com/faceyspacey/redux-first-router

Всё состояние хранится в одном месте (редакс-сторе), URL и состояние автоматически синхронизируются в обе стороны (при изменении состояния меняется URL, при нажатии на браузерную кнопку «назад» обновляется состояние), конфигурация роутов описывается централизованно и не размазывается по всему приложению. При этом API этого роутера совсем небольшой по сравнению с API Реакт-Роутера.

На React Amsterdam был хороший доклад от создателя MobX о разделении состояния и представления приложения — https://youtu.be/3J9EJrvqOiM

Лучший момент в этом докладе — когда Мишель закомментировал строчку с ReactDOM.render(...) и как ни в чём не бывало продолжил пользоваться демо-приложением прямо через консоль браузера, без UI.

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

Помимо прочего из доклада вы узнаете, как перестать зависеть от lifecycle-методов Реакта (да, можно запрашивать данные не только в componentWillMount).

Кроме этого доклада есть подробная статья, в которой пошагово демонстрируется разработка приложения с роутингом, загрузкой данных, аутентификацией и юнит-тестами без привязки к представлению — https://hackernoon.com/cc90b787aa37

Крутая демонстрация принципа работы экранов, от кинескопических до жидкокристаллических LED и OLED — https://youtu.be/hclQc7nzpN8

В package.json есть поле engines, в котором можно указать используемые в проекте версии Node и NPM. Однако установка соответствующих версий остаётся на совести разработчиков.

Чтобы у всех разработчиков использовалась одинаковая версия Node, установите нужную версию как зависимость:

npm install [email protected] -DE

Все NPM-скрипты запускаются в той версии Node, которая указана в списке зависимостей

Крутой блог и рассылка (там ещё книга есть, но её я не читал) о том, как тратить на работу меньше времени, при этом делая и получая больше — https://codewithoutrules.com/

Юридические документы не должны быть длинными и непонятными. Ребята из wheely сократили свой трудовой договор в 5 раз, просто убрав всю воду — https://wheely.com/blog/cut-the-contract/

Онлайн-журнал, работающий только в офлайне, чтобы читателя ничего не отвлекало — https://thedisconnect.co/

Если вы пишете тесты на Редакс-редьюсеры так же, как это делается в документации Редакса, не мучайтесь: http://andrew-r.ru/notes/simplified-redux-reducer-tests

Если вам или вашим детям скоро заканчивать школу, попробуйте отложить поступление в ВУЗ на год — https://mel.fm/vypuskniku/6903285-gap_year

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

Я поступил в ВУЗ сразу после школы, как и большинство моих одногруппников. При этом более чем из 30 человек в группе реально интересовались программированием ну от силы 5 человек. При таком уровне заинтересованности нет вообще никакого смысла тратить бюджетные деньги, а главное, время студентов. Зачем тогда все поступали, да ещё и на специальность, в которой не заинтересованы? Потому что так принято — после школы приличный человек должен идти в ВУЗ. А из этого следует то, что выпускники поступают не куда им действительно хочется, а куда хватает баллов.

Ваня Акулов (@iamakulov_channel) наоборот доволен тем, что пошёл в ВУЗ раньше:

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

Год между школой и вузом круто было бы потратить на работу, но, я думаю, вряд ли многие так будут делать. Какой профит идти работать и строить карьеру, если через год все равно надо будет увольняться? Плюс часть людей будет слишком молода для трудоустройства (в Украине, например, в школу идут с 6 лет и заканчивают в 17).

Так что я б советовал всё равно идти в вуз после школы, если нет прям чёткого плана, чем заниматься вместо этого

(Другой вопрос, нужно ли вообще идти в вуз. Я его заканчиваю, потому что переехать в другую страну с дипломом проще; а ещё тут довольно неожиданно оказалась пара реально полезных предметов)

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

Оказывается, на официальном сайте правительства РФ можно скачать нескучные обои для рабочего стола и даже для телефона — http://gov.ru/main/page2.html

Пару лет назад я пытался пользоваться RSS-читалкой для отслеживания новых материалов по фронтенду, но забросил это, потому что помимо неё я читал email-рассылки и ленты ВК/Твитера — получалось слишком много источников информации. Недавно обнаружил идеальный способ подписки на RSS: сервис https://blogtrottr.com позволяет подписаться на любой фид и получать по почте дайджест материалов этого фида с нужной частотой. Я так подписался на Хабр и несколько технических блогов.

Это отлично работает с концепцией пустого инбокса, когда каждое письмо во входящих считается невыполненным делом. Вместо постоянного обновления бесконечной RSS-ленты просто приходят новые письма, посмотрел письмо — дело сделано, можно удалять.

Вообще, этот сервис — хороший пример идеального интерфейса, потому что интерфейса нет (не нужно ставить себе отдельную программу для чтения RSS).

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

​​Я не очень люблю хайповые статьи в духе «Пишем список дел на (название фреймворка или технологии)». Значительно полезнее оказываются статьи и доклады о боевом опыте разработки фронтенда в реальных компаниях. Собрал большой список таких материалов: https://github.com/andrew--r/frontend-case-studies

История о том, как я радовался, что SMIL задепрекейтили и поэтому можно не тратить время на его изучение, а потом его решили РАЗДЕПРЕКЕЙТИТЬ