ReactJS *

• Работа с данными с помощью GraphQL.
• Аутентификация для API, веб- и нативных приложений.
• Создание высокопроизводительных веб-приложений
• Разработка кроссплатформенных приложений под iOS и Android
• Создание десктопных приложений.

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

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

Привет, Хабр! В Netcracker мы уже давно используем микрофронтендную архитектуру, и с 2017 года начали разрабатывать собственный платформенный инструмент построения микрофронтендов.

Недавно на митапе мы показывали, как делать сложные приложения, разрабатываемые разными командами в разных релизных циклах и даже технологиях. В режиме live coding соединили Angular, React и Vue в одном SPA. Было много вопросов про Webpack Module federation. Поскольку мы уже переходим на этот фреймворк, здесь мы поделимся наработками, как сделать Angular host application + React/Angular/Vue microfrontends с возможностью независимого версионирования зависимостей.

В 2019 году Google выпустила In-app Updates — возможность обновлять Android-приложения без перехода в Google Play. Однако до сих пор довольно мало приложений поддерживают этот способ обновления.

Когда я внедрял In-app Updates в приложение Профи для специалистов — без сложностей не обошлось. Пришлось покопаться в документации, статьях и даже пару раз переписать реализацию.

Чтобы меньше людей наступали на мои грабли, я сделал пошаговую инструкцию по интеграции In-app Updates в Android-приложение на React Native. Если следовать ей — сможете внедрить эту опцию за день.

Привет, меня зовут Сергей и я фронтендер в KTS.

Server Side Rendering часто применяется в разных проектах. Существуют крутые фреймворки для React – NextJS и Gatsby. Но в то же время любой фреймворк диктует архитектуру приложения, а это приводит к проблемам в больших приложениях. Поэтому часто можно встретить собственные сборки для SSR.

В статье описаны шаги создания собственной библиотеки для серверного рендеринга на React.

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

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

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

Как написано на сайте 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 лет). Рядовым обывателям не интересен серый сайт с непонятным содержанием. Наука становится доступнее, а сайты преобразуются в приложения с удобным и приятным интерфейсом.

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

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