JavaScript *

React без Redux, как водка без пива — деньги на ветер. Если React решает вопрос "интерфейс — функция состояния", то Redux предлагает архитектуру движения данных в приложении. Но вот незадача, что выбрать для взаимодействия с бекендом? В случае с REST-API, можно дергать Fetch, или взять чуть более функциональный Axios. Для WebSocket-ов есть Socket.io (крайне рекомендую к прочтению). А какие могут быть инструменты уровнем повыше? Реализация транспорта данных между фронтeндом и бекендом — не наша печаль.

Разрабатывать веб-фронтенд, придерживаясь JavaScript-экосистемы, всех этих новомодных штучек и пафосных фреймворков, может быть пугающим занятием, если не сказать больше. Я давно уже хотел окунуться в это, и наконец собрался с духом. К концу этой статьи, надеюсь, вы узнаете что-нибудь новое, или хотя бы чуть больше отточите свои навыки веб-разработки. Какая ирония, что длина статьи и обширное количество информации тоже могут отпугивать. Но я очень надеюсь, что вы найдёте время осилить хотя бы интересующие вас главы. В конце каждого раздела есть абзац TL;DR, так что вы можете быстро ориентироваться в содержании.

5 июня 2017 года на РИТ я рассказал доклад про то, как мы рефакторим свое огромное клиентское приложение на 2 500 000 строк кода.

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

P.S.: Заранее прошу прощение за качество видео. К сожалению, ничего с этим поделать не могу.

Содержание:

В какой-то момент борьбы со Flow-Type на VSCode, я согласился, что нужно переезжать на TypeScript. Поддержка Flow-Type обеспечивается сторонним плагином и совсем-совсем не устраивает. Если файл невалиден с точки зрения Flow-Type, то переходы внутри кода между файлами перестают работать, например. А возвращаться на WebStorm после знакомства с VSCode — я не могу себя заставить. Microsoft, как обычно, затягивает полностью. Любишь VSCode, получи TypeScript.

Если бы мне кто сказал год назад, что я вернусь в поклонники Microsoft — сложно было такое представить. Но случаются и более удивительные вещи. Я в полном восторге от качества китайского набора React-компонентов от Ant-Design. И хотя он написан на TypeScript, чтобы его прикрурить, нужен babel-plugin-import.

Но как же остаться на Create React App (CRA) — у форка для TypeScript (CRA-TS) выпилили Babel. Поддерживать собственную вариацию CRA представляется безумием. Многообещающий Preact-CLI (как замена CRA) не обеспечивает необходимый уровень совместимости с React. Но, играясь с Preact-CLI, заметил, что preact.config.js очень похож на react-app-rewired, которым я активно пользуюсь для обхода ограничений конфигурации Webpack в CRA. Сопоставил этот факт с идеей перевода CRA-TS c ts-loader на awesome-typescript-loader, внутри которого можно включить Babel. И вуаля!

Накануне запуска школы Node.js от Яндекс.Денег я хотел бы рассказать чуть больше о том, почему именно эта платформа прижилась в нашем фронтенде.

Несколько лет назад в Яндекс.Деньгах назрела смена платформы для серверной прослойки фронтенда: имевшаяся была внутренней проприетарной разработкой и постепенно умирала от слабой поддержки и проседания скорости работы. Вместе с медленной работой в рантайме и отсутствием развития XSLT, на котором работало API, этот «черный ящик» с множеством ограничений настала пора заменить.

Под «фронтендом» мы понимаем не только выполняемый в браузере код, но и серверную прослойку по сбору данных и генерации HTML. Хорошей заменой для имевшейся логики стал Node.js.

Денис Паясь (Яндекс)

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

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

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