В этой статье разберем как собрать комфортную девелопмент среду для разработки Telegram Mini App. Под комфортом я понимаю ситуацию когда тебе не нужно выгружать свое приложение в облако, чтобы увидеть результат работы в телеге, или запускать туннель типа ngrock, который после каждого перезапуска меняет ссылку. И я не уверен, что HMR можно получить через туннель. Поэтому я сделал свое решение, и хочу оставить его тут себе и потомкам.
Во многих разрабатываемых программах мы сталкиваемся с необходимостью организации работы с данными. Такие задачи могут быть самыми разными: хранение, актуализация, масштабирование и т. п. А ещё приходится реализовывать взаимодействие различных библиотек. Рассмотрим один из способов решения этих проблем при помощи React Lens.
Два года назад команда Next.js представила новый подход к роутингу, который должен был стать заменой так называемому Pages Router, вместе с тем добавив ряд принципиально нового функционала.
Практически в каждом релизе я находил множество полезного и нужного как для личных проектов, так и для коммерческих. Тем не менее, 13-ю версию я обошёл стороной для коммерческих проектов, так как функционал показывал себя крайне нестабильным и недостаточным. Однако, сейчас этот функционал перенесён в категорию стабильных, App Router считается основным, а Pages Router скорее поддерживаемым для обратной совместимости и постепенного перехода.
Next.js сделал крупный шаг, взяв на себя ответственность за кеширование и работу с запросами, добавив серверные компоненты, введя параллельные и перехватываемые роуты, а также ряд других абстракций. В этой статье речь пойдёт о причинах этого шага, возможностях, проблемах и личном мнении - был ли этот шаг в будущее или же это шаг прямиком в яму.
Frontend-разработка очень богата различными инструментами. Новые фреймворки и библиотеки выходят чуть ли не каждый день и, к сожалению, не все из них одинаково полезны или могут сделать ваш продукт лучше. Кроме того, они различаются по степени удобства именно для разработчика. Есть такое понятие DX – Developer eXperience – по аналогии с UX. Это то, насколько разработчику удобно, интуитивно понятно пользоваться определенным сервисом.
Меня зовут Аня, я frontend-специалист в компании SimbirSoft с опытом в разработке более трех лет. Уже успела поработать со многими инструментами, участвовала в проекте, где переносили огромное приложение на новые библиотеки, в том числе заменяли Redux на Effector. В этой статье хочу поделиться своими мыслями об этих стейтменеджерах с точки зрения DX.
Да, их сравнивали много раз, но мой акцент будет на том, как писать код на Effector для привычных кейсов в Redux. Подчеркну, DX — это не про рациональные аргументы, а про комфорт, фэншуй и тому подобные вещи (вы же понимаете, о чем я, правда?…).
Забегая вперед, хочу сказать, что Effector мне понравился. И прежде всего своей простотой — да-да, один из наших любимых принципов KISS). И может быть, что я по поводу Effector испытываю ещё какую-то национальную гордость, потому что это разработка ребят из России.
Всем привет! В этой статье я хотел бы рассказать про один из моих инструментов - GigaChat, ссылочка, который стал мне помощником на работе. Расскажу как его использую в повседневных рабочих задачах. Также подписывайтесь на мой канал про фронтенд, где делюсь интересной информацией, ссылочка здесь.
GigaChat - это мультимодальная модель (аналог ChatGPT от OpenAI), которую разрабатывает Сбер. В отличие от языковых моделей, мультимодальные работают не только с текстом. Они могут генерировать иллюстрации.
Привет, дорогие пользователи мира IT!
В эпоху активного развития веб-технологий и интерактивных приложений, 3D-графика становится всё более актуальной и востребованной. Но как создать 3D-приложение, не теряя преимуществ веб-разработки? В этой статье мы рассмотрим, как сочетать мощь Three.js с гибкостью React, чтобы создать собственную игру прямо в браузере.
В статье вы познакомитесь с библиотекой React Three Fiber и научитесь создавать интерактивные 3D-игры.
Мне не раз попадались такие проекты, от кода которых берет оторопь. Такое чувство, что сами авторы не смогут объяснить - почему у них все выглядит именно так. В этот момент у меня возникает вопрос: как так получилось? Если вас он тоже волнует, то могу пожелать лишь приятного чтения.
Порою, заходя в стили проектов, я невольно пугаюсь сложившейся длине имён - модуль, блок, элемент, подэлемент, модификатор 1, модификатор 2. Длинные классы увеличивают вес страницы, это в свою очередь означает увеличение времени загрузки самого главного для рендера страницы - документа и файла стилей, от которых напрямую зависят метрики FCP, LCP.
Вместо них можно использовать модули - они дают возможность называть классы короче, только под текущий компонент, сохраняя при этом удобство разработки. Но в качестве планы добавляет к классам хеши, делая их длиннее, а значит преимущество не такое, как хотелось бы...
Всем привет!
Спешу сообщить о выходе новой версии замечательной фронтенд-библиотеки Symbiote.js! Никогда не слышали о ней? Самое время познакомиться.
Symbiote - это компактная, но очень мощная библиотека для создания веб-компонентов и приложений на их основе. Да, я знаю, у нас уже есть React, Vue, Svelte, LitElement и прочее. И может быть, не очень понятно, зачем вникать во что-то еще… Но не торопитесь с выводами, Симбиоту есть, что вам предложить.
В сети можно найти огромное количество статей, мануалов и книг по основам React, включая официальную документацию от разработчиков. В этой статье мы не будем писать HelloWorld и изучать общеизвестные концепции. Сегодня мы заглянем под капот библиотеки и попытаемся понять, как она устроена внутри, как хранит данные, и как, на самом деле выглядит её виртуальное дерево.
На момент написания статьи, последняя стабильная версия React 18.2.0. За 10 лет разработчики Facebook проделали колосальный объем работы, было реализовано много фич и сделано не мало оптимизаций. За эти годы, так же, происходили и кардинальные архитектурные изменения. Очевидно, одной статьи мало, чтобы покрыть всю механику React, поэтому, данная публикация станет первой в серии статей о внутреннем устройстве React. Здесь мы познакомимся с основными сущностями и архитектурными решениями.
Под конец прошлого года, по ряду причин, ESLint отказались от дальнейшей поддержки и развития стилистических правил. А тема, как по мне, несправедливо осталась в тени. Давайте разберемся, почему так произошло и какие изменения нас ждут на поприще статического анализа и форматирования кода.
Привет! В данной статье мы разберём процесс разработки веб-приложения на основе подхода микрофронтендов с использованием технологии Module Federation
Всем привет! В этой статье (части) рассмотрим вопросы, связанные с великим и могучим TypeScript'ом, которые задают на собеседованиях. Если вы не читали прошлую статью, где описаны вопросы по JS, вот ссылочка. Пожалуйста, не заучивайте вопросы, это вредно для вашего здоровья!)
Всем привет! Меня зовут Олег и я fullstack-программист в компании Тензор. Опыт в разработке, без малого, 20 лет (как-то раз батя спаял на кухне ZX Spectrum и все заверте..., сам не понял как так вышло). В данный момент являюсь тимлидом собственной команды разработчиков, которая периодически нуждается в пополнении толковыми программистами.
Как и многие руководители, я активно принимаю участие в подборе сотрудников для себя и помогаю на собесах коллегам соседних отделов.
Наша команда занимается разработкой веб-приложения на React. Соответственно, мне важно найти программистов уверенно владеющих основами (!) этого фреймворка. Есть много способов проверки компетенций на собеседовании, один из любимых - задача по написанию hook для загрузки данных.
Если вы тоже в вечном поиске классных фронтендеров или сами часто проходите собесы - велком в эту статью :)
Хуки позволили нам перейти с классового компонента на функциональный. Они решили проблему хранения состояния между перерисовками функционального компонента и отчасти упростив написание логики. Почему же я предлагаю отказаться от них?
react-afc - библиотека для более простого уменьшения количества ненужных ререндеров дочерних компонентов.
Здравствуйте!
Коротко о чем тут, чтобы вы могли понять, нужно ли оно вам или нет.
Тут я описываю то к чему я пришел в разработке именно компонентов и какой подход использую. Материал может быть полезна скорее для новичков и не обязательно в React, потому что этот подход подойдет и для всего остального, но примеры на React.
Сразу напишу, что это, скорее, не статья, а открытие дискуссии. Я уверен, что по этой теме было создано огромное количество материала, но вдруг в момент выхода моего — какой‑нибудь прошлый я прочтет это и о чем‑нибудь задумается. Если это поможет хотя бы одному — это было не зря.
Почему это дискуссия? Потому что я не могу утверждать, что это правильное решение или что это в принципе хорошее решение для действительно больших проектов. Я не знаю. Но в тоже время, чисто логически, это выглядит как правильное решение и все последние проекты которые я делал с этим подходом — легко поддерживаются и разрабатываются. Надеюсь, что более опытные разработчики оставят отзыв или комментарий на эту тему и по этому материалу.
И снова всем привет! Продолжение к переводу второй части книги Patterns.dev
В ней речь идет про паттерны производительности. Узнайте, как оптимизировать последовательность загрузки, чтобы повысить скорость использования вашего приложения и др.
Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed Insights, Chrome User Experience Report и другими.
Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей третьей части учебника можно найти здесь.
P. P. S.: Третья часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0
Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
При работе с React и TypeScript вы часто сталкиваетесь с подобными ошибками:
const onChange = (e) => {}; // Parameter 'e' implicitly has an 'any' type.
<input onChange={onChange} />;
Не всегда понятно, какой тип следует присвоить пременнойe внутри функции onChange.
Это может произойти с onClick, onSubmit или любым другим обработчиком событий, которые получают элементы DOM.
К счастью, есть несколько решений:
Когда мою команду попросили обновить приложение, мы выпустили вполне себе успешный релиз — ровно в том виде, в котором нас просили. Старались придерживаться изначальной концепции: нужно было поддержать редизайн и переход веб-версии на React JS, расширить функции и убрать несколько технических ошибок.
Тогда мы сделали приложение, в котором изначально был задуман ряд экранов. Вроде ничего необычного, пойдет! И все бы хорошо, только при первом запуске в них легко было запутаться и вообще отказаться от приложения. Ведь, регистрируясь в какой-то программе, люди не ожидают увидеть что-то сложное. Им важно быстро понять, что и как там делать, чтобы сразу начать пользоваться. Мы придумали, как выйти из положения!
