Недавно я закончил писать серию постов о том, как я построил шахматную доску с помощью React. Шахматная доска обрабатывает очень мало пользовательских взаимодействий, потому что она предназначалась для меня, чтобы поэкспериментировать с некоторыми функциями CSS3 и HTML5. Позже, когда я включил в React несколько более современных функций (Context API и библиотеку компонентов React MUI), я начал думать о работе над новым проектом, в котором я смогу поиграть с более продвинутыми вещами React.

И в итоге я создал веб-судоку.

Вы можете начать соревноваться с моими головоломками Судоку на https://sean-sudoku.netlify.app/. Код в настоящее время размещен на GitHub по адресу https://github.com/seanluong/sudoku.

Есть несколько интересных задач, которые мне пришлось решить, чтобы завершить приложение как во внешнем, так и в бэкэнде.

Создание интерфейса

Использование React MUI

Я построил весь пользовательский интерфейс, используя компоненты React MUI. С шахматной доской я полагался в основном на макет на основе стека, поэтому на этот раз я использовал макет на основе сетки для доски судоку. Я также работал с несколькими другими компонентами, которые не использовал для шахматной доски, а именно FAB, Группа кнопок и Текстовое поле. В целом у меня не было особых претензий к качеству библиотеки компонентов, поскольку большая часть того, что мне было нужно, было очень хорошо документировано.

Один урок, который я извлек из этого проекта, заключается в том, что я не очень уверен в том, какие преимущества предлагает сетка по сравнению со стеком? Под капотом компонента Сетка в библиотеке React MUI реализована блочная модель CSS flex, которая также является основой Стека. Если кто-то действительно хочет воспользоваться преимуществами макета CSS grid, ему придется воспользоваться мощью системы MUI.

MUI System — это набор утилит CSS для быстрого создания пользовательских дизайнов с помощью библиотек компонентов MUI.

Управление государством

Я использовал две вещи для управления состоянием приложения: Redux и Context API.

Сначала я просто использовал Redux для всего. Причина заключалась в том, что с тех пор, как я в последний раз работал с Redux, прошло некоторое время, поэтому я хотел освежить свои знания. Изменилось довольно много вещей, и приятно видеть, что библиотека со временем претерпевает некоторые улучшения.

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

Еще одна замечательная вещь, о которой следует упомянуть, — это хуки, предоставляемые библиотекой react-redux, в частности useDispatch и useSelector. Я думаю, будет справедливо сказать, что любое новшество, внесенное в экосистему React, не будет полным, пока оно не будет дополнено собственными зацепками!

Как бы мне ни нравилось работать с современным Redux, я не мог не задаться вопросом, будет ли это по-прежнему применяться в экосистеме React, когда дело доходит до управления состоянием? В последнее время, кажется, появляется новая тенденция, когда люди уходят от Redux и его багажа, используя контекстный API React и несколько хуков, которые уже включены в библиотеку React. На эту тему есть отличный пост в блоге здесь.

В этом проекте я использовал Context API только для управления состоянием того, следует ли показывать пользователям ошибки, которые в настоящее время существуют в их решении головоломки судоку. В будущем проекте я, вероятно, буду экспериментировать с использованием Context API вместо Redux для управления состоянием.

Создание серверной части

В начале я не предполагал иметь бэкэнд часть для этого проекта. Работая над созданием головоломки судоку, я решил, что не буду сам писать код генерации головоломки. Хотя я был вполне уверен, что, если у меня будет достаточно времени, я смогу придумать какой-нибудь алгоритм для создания головоломок и даже прочитать о предыдущих исследованиях о том, как создавать головоломки на разных уровнях сложности, мне не хотелось опускаться. этот путь максимизировал бы мой опыт обучения в проекте в том, что касается создания веб-приложения. Я подумал, что было бы веселее, если бы я мог найти конечную точку API, где я мог бы сделать запрос на получение головоломки и получить ее в ответ.

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