Пользователь
Привет, друзья!
Представляю вашему вниманию перевод этой статьи, вызывавшей определенный резонанс в сообществе React-разработчиков.
Дорогой React, мы встречаемся уже почти 10 лет. Мы прошли долгий путь вместе. Но ситуация вышла из-под контроля. Нам нужно поговорить.
Nextjs — самый быстрорастущий фреймворк. После создания, в 2016 году, было выпущено уже 12 обновлений, каждое из которых называлось компанией “крупнейшим”. 25 октября Vercel (компания, владеющая Nextjs) представит новый, 13 релиз, который, конечно же, вновь станет “крупнейшим”. Тем не менее, в этой статье речь пойдёт не конкретно о нём, а о действительно новом для компании процессе.
В мае этого года Nextjs неожиданно выпустил в своём блоге RFC (request for comments). В нём речь идёт, в первую очередь, о новой абстракции — layouts, а также о множестве связанных изменений, нацеленных на ускорение, улучшение DX и стандартизацию путём создания новых конвенций. Это рабочее предложение однозначно заслуживает внимания в меру своей громоздкости для фреймворка и потому, что буквально описывает его будущий вид.
25 октября команда Next проведёт презентацию, посвящённую новой, 13-ой версии. Данное обновление по традиции именуют крупнейшим. Оно может затронуть буквально всё — от очередных ускорений сборки до изменений в структуре приложения и новых абстракций.
Next.js — крупнейший фреймворк для разработки веб-приложений. Он был создан 6 лет назад, 25 октября 2016 года. За это время было выпущено 12 крупных релизов, делая веб всё быстрее и быстрее. Несмотря на громоздкость фреймворка, размеры каждого последующего релиза не становились меньше, хоть и замедлялись в темпах.
Три года назад команда Next.js впервые провела конференцию, посвящённую релизу и сделала её ежегодной. Исключением стала презентация 11-ой версии, которая прошла в июне 2021 года. В данной статье речь пойдёт о том, какой функционал был завершён в последних обновлениях и что может нас ждать на завтрашней конференции.
Как часто рано или поздно при решении новой задачи приходит мысль: а нельзя ли для неё переиспользовать код из реализованной ранее аналогичной задачи? Думаю, что в такой момент нами движет что-то среднее между ленью и здравым смыслом. Ну не писать же всё с нуля? Далее появляется подлая мыслишка: а может, просто «скопипастить» и не заморачиваться?
Данная статья продолжение статьи про мемоизацию, в которой мы разбирали зачем нужно использовать memo и как правильно с ним работать. В этой статье разберем, как правильно использовать useMemo и useCallback, какое у них api и разберем пару трюков. В прошлой статье я писал, что в следующей будет информация про useRef, useImperativeHandle и прочее, но в итоге решил, что текущий материал можно объяснить проще. Только трюки подведут нас к использованию useRef и уже в следующей лекции мы разберемся с ним.
Привет, друзья!
Представляю вашему вниманию перевод этой небольшой заметки, посвященной предложению нового хука React.
Первоклассная поддержка промисов в React — как это должно работать
Новое предложение от команды React вызвало некоторую шумихи в экосистеме React: одни разработчики с нетерпением ждут новых возможностей, другие выражают обеспокоенность тем, как это будет реализовано. В этой статье мы поговорим о том, что из себя представляет новая возможность, какие проблемы она решает, а также о сложностях, которые могут возникнуть в процессе ее реализации и применения.
Использование ref в функциональных компонентах играет две роли:
1. С помощью них можно получить ссылку на dom элементы и react компоненты
2. ref можно использовать как стабильные переменные.
В этой статье сосредоточимся на первой роли, разберем, как с помощью ref получить доступ к dom элементам и компонентам react, включая такие какие способы как createRef, useRef и ref callback. Обсудим для чего нужны forwardRef и useImperativeHandle , и как с их помощью получить ссылку на функциональные компоненты, спойлер: нельзя так просто получить ссылку на функциональный компонент с помощью ref. А уже в следующей статье обсудим роль ref в качестве стабильной переменной, и как это облегчит нам жизнь при использовании useEffect, useMemo, useCallback.
В этой статье я бы хотел подискутировать о том, насколько хорошо паттерн MVVM подходит для разработки Web приложений на React. Вместе этим, я собираюсь описать какие преимущества могут быть при разработке с использованием MobX с паттерном MVVM в сравнении с Redux. Запаситесь кофе, это будет долгое чтиво.
Redux и MobX больше не нужны ?
Туториал для новичков по EffectorJS - современному и удобному стейт-менджеру. Рассмотрим основные возможности, работу ядра, и какие проблемы решает. На примерах.
Команда Vercel порадовала нас большим релизом популярного фреймворка Next.js, давайте вместе разберёмся, что там изменилось и появилось нового
По отдельности хуки могут быть относительно понятны, но у многих возникают вопросы, как их использовать вместе. Особенно часто возникают подобные вопросы при переходе от классовых компонентов к функциональным. В этой статье мы разберем несколько случаев:
Как работать с запросами в useEffect
Как предотвращать лишние запросы в useEffect с помощью useRef и использовать useRef как стабильную переменную
Уже этих примеров будет достаточно для многих прочих случаев. Главное обсудим, как ведет себя замыкание в хуках, почему именно так, и почему useRef работает как стабильная переменная.
Пошаговое руководство по настройке сборщика Webpack 5 совместно с такими инструментами как Pug, Sass, JavaScript, React и Markdown.
React vs Vue vs Angular. Общее сравнение JavaScript фреймворков
В ходе развития веб-разработки 3 JavaScript-фреймворка стали хорошо известны всем front-end разработчикам: React, Vue и Angular.
React считается библиотекой пользовательского интерфейса, Angular - полномасштабным front-end фреймворком, предоставляющим собственные инструменты для всех связанных с разработкой веб-приложений функций, а Vue - прогрессивным фреймворком, реализованным как дополнительная разметка для HTML.
Все три фреймворка могут использоваться практически взаимозаменяемо для создания компонентных frontend-приложений с расширенными возможностями пользовательского интерфейса. Однако окончательный выбор зависит от требований проекта и предпочтений разработчика.
Каждый фреймворк имеет различную архитектуру, производительность в различных сценариях, экосистему и инструменты, которые мы постараемся рассмотреть в этой статье, чтобы лучше понять их удобство использования.
В своей прошлой статье я рассуждал о том, как использование паттерна MVVM позволяет упростить процесс разработки. Паттерн был реализован с применением библиотеки MobX. Эту библиотеку я считаю в разы удобнее Redux, аргументы в пользу чего я также привел в статье. Однако, у нее имеется серьезный недостаток - излишняя свобода действий, в следствие наличия которой разработчики не всегда знают как писать код "хорошо". Паттерн MVVM же диктует несколько простых правил по использованию MobX, благодаря которым разработчики могут реже наступать на грабли. Однако, он не решает всех проблем. И в этой статье я бы хотел показать, как можно дополнить паттерн MVVM и сделать процесс разработки ещё приятнее.
Привет! Сегодня поговорим про стандартные способы оптимизации web-приложения в экстремистской библиотеке React. Мотивацией послужило некоторое количество кода, который я видел. Связан он с использование API React не по назначению или без учета каких-то очевидных проверок на производительность и тонкостей (с натяжкой).
Привет, друзья!
Представляю вашему вниманию перевод этой замечательной статьи.
Многие React-разработчики спрашивают себя: надо ли мне учить TypeScript? Еще как надо!
Преимущества изучения TS могут быть сведены к следующему:
Эта статья представляет собой минимальное введение по использованию TS в React.
Антигероем нашей истории будет Пэт — очень неприятный технический директор.
Всем привет!
Все мы прекрасно знаем что построить полноценный стор на react context достаточно тяжело, а оптимизировать его ещё тяжелее.
А что если я расскажу как это можно сделать быстро и просто?
Как мы все знаем, в React есть функциональные и классовые компоненты. Каждый вид имеет свои плюсы и минусы.
Классовые компоненты имеют меньшую производительность по сравнению с функциональными и вызывают некоторые сложности в переиспользовании одинаковой логики.
Технология css-in-js существует уже довольно давно. Ещё в начале своего профессионального опыта я встречал подходы, в которых стайлинг локальных частей интерфейса пробрасывался в html через javascript в виде css директив. Иногда это необходимая мера, хотя необходимой она случается изредка, но раз в год, как говорится, и палка стреляет. У меня на опыте был пример построения раздела интерфейса, в котором устанавливаемое на сайт пользователя модальное окно можно рестайлить через кодовый редактор с live preview. css-in-js бывает оправдан, поэтому хочу сразу оговориться - хоронить никакой подход не стоит. Но и идеализировать его как универсальную пилюлю тоже не надо. Рендер стилей, привязанный к логике рендера компонентов в контексте всего проекта - это просто свой путь со своими приключениями, появившийся на мой взгляд в общей психопатии привязывать к state всё что только можно. Что если посмотреть - откуда взялась эта техногогия? На сегодняшний день на рынке проектирования интерфейсов сложился монополист react, диктующий программистам свои правила игры, и который даже без использования styled модуля имеет в себе простейщую инверсию управления cssInJs.
React - важный персонаж в этой теме. Он, словно useEffect всего современного front-end - стал центром силы, средоточием зла в виде голого state management, не предусматривающего из коробки ничего иного.