Если вы какое-то время работали с React, вы, вероятно, столкнулись с дизайном или экраном, который включает форму. Форма, в которой пользователь вводит текст, число или выбирает элемент из раскрывающегося списка в зависимости от бизнес-требований.

Когда дело доходит до работы с формами в React, вам в первую очередь следует установить Formik и Ага, верно? Что ж, я согласен, что они так хорошо сочетаются и облегчают работу! Намного проще!

В последние несколько недель или месяцев я размышлял, как это будет выглядеть, если у нас есть схемы? Я продолжал копать и раскапывать эту мысль. Было бы здорово? После долгих размышлений, я думаю, мне пришла в голову революционная мысль. Я спросил себя, Ага только для Формика? Разве Ага нужно использовать только с Формиком?

Ответ - нет, и я поделюсь с вами тем, что я узнал!

🤔 Почему именно схемы?

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

Схема похожа на контейнер для структуры. Структура описывает, как определенное поле будет отформатировано или сохранено. Я думаю об этом как о метаданных, в которых подробно описывается конкретное поле.

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

🧭 Изучение необычного

Я хотел бы сказать, что эта попытка является экспериментальной и не подвергалась тщательной проверке, по крайней мере, на данный момент. Честно говоря, я не решался попробовать это, потому что, если вам придется подумать об этом, похоже, что это не подходит. Это было необычно. Но я не могу выбросить это из головы, когда пишу код. Это всегда входит в ход моих мыслей. Код любви?

Пример приложения, которым я поделюсь с вами, посвящен отправке и получению данных в конечную точку API с использованием схем.

Давайте сначала отправим данные в конечную точку API. Сравните с текущим подходом и попытайтесь понять, лучше ли он подход, основанный на схеме. Допустим, наша конечная точка принимает следующую схему.

Самый простой подход - получить значения формы из Formik и выполнить HTTP-вызов с помощью fetch или Axios для отправки запроса.

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

Давайте посмотрим на разницу между первым усовершенствованным подходом и подходом на основе схемы.

В подходе, не основанном на схеме, используется функция переименования свойств ES6, а в другом - функции Ага для переименования свойства и создания объекта. На самом деле мы можем использовать подход ES6 к схемам, но я хотел проиллюстрировать его простым подходом без смешивания для ясности. Что вы думаете об этом?

Теперь, когда мы увидели, как мы можем использовать схему при отправке HTTP-запроса к API, давайте попробуем на этот раз, как мы можем использовать схему при получении запроса. Давайте также добавим несоответствия в схему API, которую мы получаем. Несоответствие схемы API неизбежно, и поэтому я думаю, что это всегда отличный пример.

Схема API теперь использует форматирование регистра змейки, давайте посмотрим, как мы можем подойти к этому.

Мы снова использовали функцию переименования свойств ES6 в нашем первом подходе, а во втором подходе мы снова использовали те же методы из Ага, но на этот раз мы не использовали метод приведения на ранней стадии.

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

Теперь мы стали свидетелями нескольких примеров получения и отправки данных в API с использованием подхода, не основанного на схеме, а на основе схемы. Что вы думаете об этом?

🤖 Собираем все вместе

Что мне нравится в схеме на основе, так это то, что она обеспечивает лучшую композицию поля объекта и возможность выразить, как структура должна формироваться внутри. Помимо этих примеров, использование на основе схемы также позволит вам добавлять проверки из Ага и другие преобразования, которые изначально доступны в нем.

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

Я вижу, что есть много вещей, которые мы можем изучить вместе с помощью этого подхода, основанного на схемах. Это только начало, и по мере того, как мы вступаем в неизведанное, нам предстоит многое сделать.

Спасибо за чтение. Надеюсь, это поможет вам в вашем путешествии! ❤️