ReactJS *

Где же держать бизнес логику приложения?

 "Та че уж там парится - прямо в компонентах." - скажут некоторые. И в некоторых ситуациях это правильное и удобное решение.

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

Как написано на сайте reactjs.org, React - это библиотека для создания UI. 

А для модели и бизнес логики написано несколько других замечательных библиотек.

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

React существует достаточно давно, чтобы мажорные изменения в этой библиотеке, не ощущались температурой подогрева кресел разработчиков в холодные зимние вечера (не благодарите за лайфхак). Но Facebook сделали ход конем и в свое время выпустили не мажорную, а минорную версию и тем самым сняли с себя ответственность за нестабильность уже существующих миллионов репозиториев, как вы уже поняли я буду рассказывать про версию 16.8.0, а так как мы почти никогда не используем React без Redux в продакшн репозиторияx, то и про него скажу. 

И сперва давайте поговорим про React. Почему была упомянута нестабильность после внесения “дополнений” 16.8.0, проблема в том что она произошла в головах разработчиков - легким движением руки Facebook сказал нам, знаете, ООП это конечно же хорошо, но функциональный подход лучше. И тут особо ярые и продвинутые ринулись кидать уже существующий подход Statefull Components и Stateless Components и дописывать новыe functional Components с его хуками useState, useCallback, useEffect etc. и только лишь иногда useContext.

Штош, в самих этих 4-х функциях я ничего плохого и не вижу, в общем-то:

В данной статье я хочу описать известные мне способы встраивания mapbox-gl в React приложение, на примере создания простого веб приложения содержащего карту на Next.js с использованием Typescript, код компонента карты можно также использовать в любом любом приложении на React

Здравствуйте, меня зовут Дмитрий Карловский и я… люблю рвать шаблоны. А во фронтенде как раз крайне много заблуждений вокруг шаблонизации. Так что давайте порвём их на лоскуты снизу вверх и справа налево.

Далее мы разберём что такое шаблоны. Их ключевые достоинства и фатальные недостатки. Зачем они нужны и почему не нужны. Сформируем представление о правильном решении и проедемся катком по популярным. Так что полная гамма чувств нам обеспечена.

24 июня прошел четвертый митап по JavaScript под названием Frontend Mix. В этот раз разработчики делились экспертизой в онлайн-формате. Делимся долгожданными видео и нашим опытом во фронтенд-разработке.

В процессе моей работы в geoalert.io я не раз сталкивался с проблемой управления состоянием приложения на React со встроенной картой mapbox-gl.

Я планирую посвятить теме цикл из трех статей, включая эту:

1. Управление состоянием mapbox-gl в React

2. Встраивание mapbox-gl в React

3. Управление состоянием React приложения сmapbox-gl с использованием XState

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

Пару слов о технологии, если кто-то умудрился обойти ее стороной. Next – backend-фреймворк для… Инкрементальной сборки, Серверного рендеринга, статической генерации или гибридного варианта приложений, построенных на react. Созданием занималась компания zeit, имеющей к 2016г. утилиту now. Затем, в 2020 году, после инвестиций в 21 млн$, компания была переименована в vercel, а утилита now (переименованная также в vercel) переросла в веб-сервис с дополнительным функционалом для выкладки приложений, в первую очередь, построенных на next, но также nuxt, Gatsby, angular и многих других популярных инструментов.

Редакс - Single-store стейт-менеджер, в котором к тому же принято группировать данные по объектам. Примерно так же, как в стейте классовых компонентов в реакте.

То есть, это совершенная противоположность атомарного подхода, которому, к примеру, следуют многие хуки реакта или Multi-store стейт-менеджеры (например Effector, где селекторы не нужны по определению - достаточно сторов).

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

В общем, раз в редаксе нет возможностей ни эффектора, ни MobX, нам лишь остается напрямую обращаться к данным, начиная с самого верха. Это превращается в нечто вроде state.foo.bar.baz. А если перед этим еще нужно произвести какие-то вычисления с участием других значений из стора?

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

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

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

Когда веб только зарождался – единственной его целью было размещение контента (гипертекстовые страницы), чтобы у пользователей из всемирной паутины был к нему доступ. В то время не могло идти и речи о дизайне, ведь зачем нужен дизайн страницам с научными публикациями, разве они станут от этого полезнее (первый сайт). Времена меняются и сегодня во всемирной паутине далеко не только научные публикации. Блоги, сервисы, социальные сети и многое, многое другое. Каждый сайт нуждается в своей индивидуальности, ему необходимо заинтересовывать и привлекать пользователей. Даже научные сайты постепенно это понимают, ведь большинство ученых хотят не просто изучать те или иные аспекты, а доносить их до людей, тем самым повышая свою популярность и ценность своих исследований (пример – 15 из 15 научных сайтов списка сделали редизайн в последние 6 лет). Рядовым обывателям не интересен серый сайт с непонятным содержанием. Наука становится доступнее, а сайты преобразуются в приложения с удобным и приятным интерфейсом.

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

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

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

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

Около года назад в Techgoise я получил возможность поработать с большим React-приложением. Мы получили (унаследовали) готовую кодовую базу, внесли основные правки и начали добавлять в приложение новые интересные возможности.

Однако, мы часто получали жалобы от тестировщиков и конечных пользователей о том, что они видят эту злополучную ошибку. После проведенного анализа мы установили, что причина происходящего состоит в том, что приложение расходует целых 1,5 Гб памяти!

В данной статье я расскажу о том, как нам удалось добиться уменьшения этой цифры с 1,5 Гб до 150 Мб, что, как следствие, привело к улучшению производительности почти в 10 раз, и мы больше никогда не сталкивались с Ошибкой.

Поиск узких мест в производительности

Существует большое количество инструментов и библиотек для обнаружения узких мест в приложении. Мы испытали большое количество таких инструментов. Ниже представлено три из них, которые оказались наиболее полезными.

1. Профилирование компонентов с помощью расширения для Google Chrome

В прошлом посте я рассказывал об учебнике по настройке react-router. Если вы не читали предыдущий пост, нажмите здесь! Я хочу добавить несколько важных тем о методах рендеринга маршрутов.

Это вторая часть туториала, посвященного реализации Real World App — подписки на обновления с помощью гугл таблиц, бессерверных функций и реакта.

Вот ссылка на первую часть.

Напомню, что основной функционал нашего приложения, который мы реализовали в первой части туториала, является следующим:

• на главной странице отображается приветствие и предложение подписаться на обновления
• при нажатии на кнопку «Подписаться», пользователь попадает на страницу с формой, содержащей два поля: имя и адрес электронной почты
• для защиты от ботов используется гугл рекапча 2 версии
• при заполнении полей и прохождения проверки снимается блокировка с кнопки «Подписаться»
• при нажатии этой кнопки данные пользователя отправляются в таблицу с помощью бессерверной функции

Дополнительный функционал, реализацией которого мы займемся в этой части:

• с помощью скрипта осуществляется автоматическая рассылка уведомлений
• в рассылаемых письмах содержится ссылка на отписку от обновлений
• при переходе по этой ссылке адрес электронной почты передается бессерверной функции, с помощью которой из таблиц удаляется соответствующая строка

У каждого из вас может возникнуть потребность поработать с графикой при создании React-приложения. Или вам нужно будет отрендерить большое количество элементов, причем сделать это качественно и добиться высокой производительности при перерисовке элементов. Это может быть анимация либо какой-то интерактивный компонент. Естественно, первое, что приходит в голову – это Canvas. Но тут возникает вопрос: «Какой контекст использовать?». У нас есть выбор – 2d-контекст либо WebGl. А как на счёт 2d-графики? Тут уже не всё так очевидно.

В этом туториале мы реализуем ~~Real World App~~ — подписку на обновления с помощью гугл таблиц, бессерверных функций и реакта.

Основной функционал нашего приложения будет следующим:

• на главной странице отображается приветствие и предложение подписаться на обновления
• при нажатии на кнопку "Подписаться", пользователь попадает на страницу с формой, содержащей два поля: имя и адрес электронной почты
• для защиты от ботов используется гугл рекапча 2 версии
• при заполнении полей и прохождения проверки разблокируется кнопка "Подписаться"
• при нажатии этой кнопки данные пользователя отправляются в таблицу с помощью бессерверной функции

Дополнительный функционал:

• с помощью скрипта осуществляется автоматическая рассылка уведомлений
• в рассылаемых письмах содержится ссылка на отписку от обновлений
• при переходе по этой ссылке адрес электронной почты передается бессерверной функции, с помощью которой из таблиц удаляется соответствующая строка — пользователь больше не будет получать уведомлений

В первой части туториала мы реализуем основной функционал, во второй — дополнительный.