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

0 3

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

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

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

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

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

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

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. И эта парадигма совершенно естественна для веб-пользователей — обмен ссылками был частью всемирной паутины с момента ее изобретения!

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

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

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

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

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

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

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

Вы можете использовать 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);

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

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

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

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)} … /> ) }

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

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

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

И это все! Это так просто. Что замечательно в 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}

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

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

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

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

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

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

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

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

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

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

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

Автор: Sidney Alcantara

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

Оставьте ответ