Как и почему вы должны хранить состояние React UI в URL-адресе

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

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

Возвращение диплинков в Web

Появление одностраничных приложений (SPA) позволило нам создавать новые user experiences, которые мгновенно интегрировались в Web. Делая больше на стороне клиента с помощью JavaScript, мы можем немедленно реагировать на пользовательские события, от открытия пользовательских диалоговых окон до текстовых редакторов, таких как Google Docs.

React JS. Основы

Изучите основы ReactJS на практическом примере по созданию учебного веб-приложения

Получить курс сейчас!

Традиционные серверные веб-сайты каждый раз отправляют запрос на получение новой HTML-страницы. Отличным примером является Google, который отправляет запрос на свои серверы с поисковым запросом пользователя в URL-адресе: https://www.google.com/search?q=your+query+here. Что хорошего в этой модели, так это то, что если я отфильтрую результаты за последнюю неделю, я могу поделиться одним и тем же поисковым запросом, просто поделившись URL-адресом: https://www.google.com/search?q=react+js&tbs=qdr:w. И эта парадигма совершенно естественна для веб-пользователей — обмен ссылками был частью всемирной паутины с момента ее изобретения!

Когда появились SPA, нам не нужно было хранить эти данные в URL-адресе, поскольку нам больше не нужно было делать запрос к серверу, чтобы изменить то, что отображается на экране. Но это позволило легко потерять уникальный experience, ссылку, которой можно поделиться.

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

Очень простые диплинки

При создании веб-приложения с несколькими страницами как минимум необходимо изменить URL-адрес при отображении другой страницы, например /login и /home. В экосистеме React, React Router идеально подходит для такой маршрутизации на стороне клиента, а Next.js — отличная полнофункциональная среда React, которая также поддерживает рендеринг на стороне сервера.

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

Вы можете использовать npm пакеты, такие как query-string, и написать базовый React Hook для синхронизации параметров URL-запроса с вашим состоянием, и для этого есть множество руководств, но есть более простое решение.

Изучая современные библиотеки React для управления состоянием, для переписывания архитектуры нашего React-приложения, я наткнулся на крошечную библиотеку состояний Jotai, вдохновленную библиотекой Recoil команды React.

Основное преимущество этой модели заключается в том, что части состояния объявлены независимыми от иерархии компонентов, и ими можно манипулировать из любого места в приложении. Это решает проблему с React Context, вызывающую ненужную повторную визуализацию, которую я ранее обходил с помощью useRef. Вы можете прочитать больше о концепции атомарного состояния в документации Jotai, а более техническую версию — в документации Recoil.

Код

В Jotai есть тип под названием atomWithHash, который синхронизирует атом состояния с хешем URL. Предположим, мы хотим, чтобы открытое состояние модального окна сохранялось в URL-адресе. Начнем с создания атома:

JavaScript import { atomWithHash } from “jotai/utils”; export const modalOpenAtom = atomWithHash(“modalOpen”, false);

123	import { atomWithHash } from “jotai/utils”; export const modalOpenAtom = atomWithHash(“modalOpen”, false);

Затем в самом модальном компоненте мы можем использовать этот атом точно так же, как useState:

React JS. Основы

Изучите основы ReactJS на практическом примере по созданию учебного веб-приложения

Получить курс сейчас! JavaScript import { useAtom } from “jotai”; import { modalOpenAtom } from “./atoms”; function ExampleModal() { const [open, setOpen] = useAtom(modalOpenAtom); return ( <Dialog open={open} onClose={() => setOpen(false)} … /> ) }

12345678910111213

import { useAtom } from “jotai”;import { modalOpenAtom } from “./atoms”; function ExampleModal() {  const [open, setOpen] = useAtom(modalOpenAtom);  return (    <Dialog      open={open}      onClose={() => setOpen(false)}      …    />  )}

Вот как это выглядит:

И это все! Это так просто. Что замечательно в atomWithHash от Jotai, так это то, что он может хранить любые данные, которые может использовать useState, и автоматически упорядочивает объекты для хранения в URL-адресе. Таким образом, я могу хранить более сложное состояние в URL-адресе, делая его доступным для совместного использования.

В Rowy мы использовали эту технику для реализации пользовательского интерфейса для облачных логов. Мы создаем платформу с открытым исходным кодом, которая упрощает разработку бэкэнда и устраняет разногласия в стандартных рабочих процессах. Таким образом, снижение разногласий при совместном использовании логов было для нас идеальным. Вы можете увидеть это в действии на демонстрации, где я могу связать вас с конкретным логом развертывания:

JavaScript https://demo.rowy.io/table/roadmap#modal=”cloudLogs”&cloudLogFilters={“type”%3A”build”%2C”timeRange”%3A{“type”%3A”days”%2C”value”%3A7}%2C”buildLogExpanded”%3A1}

1	https://demo.rowy.io/table/roadmap#modal=”cloudLogs”&cloudLogFilters={“type”%3A”build”%2C”timeRange”%3A{“type”%3A”days”%2C”value”%3A7}%2C”buildLogExpanded”%3A1}

Декодирование компонента URL показывает точное состояние, используемое в React:

JavaScript cloudLogFilters = { “type”: “build”, “timeRange”: { “type”: “days”, “value”: 7 }, “buildLogExpanded”: 1 }

12345

cloudLogFilters = {  “type”: “build”,  “timeRange”: { “type”: “days”, “value”: 7 },  “buildLogExpanded”: 1}

Дополнительный эффект atomWithHash заключается в том, что он по умолчанию отправляет состояние в историю браузера, поэтому пользователь может нажимать кнопки «назад» и «вперед» для перехода между состояниями пользовательского интерфейса.

Это поведение является необязательным и может быть отключено с помощью параметра replaceState:

JavaScript const modalOpenAtom = atomWithHash(“modalOpen”, false, { replaceState: true, });

123	const modalOpenAtom = atomWithHash(“modalOpen”, false, {  replaceState: true,});

Спасибо за чтение! Я надеюсь, что это убедило вас показать больше состояния вашего пользовательского интерфейса в URL-адресе, сделав его доступным и уменьшив неудобства для пользователей, особенно потому, что это легко реализовать.

Автор: Sidney Alcantara

Источник: webformyself.com