Хранение информации



Способы и Формы Хранения Данных

HTML-формы. Взгляд бэкенд-разработчика из песочницы  Январь 6, 2020 – 22:27

imageРаньше работа с формами была в каком-то смысле проще: в том виде, в котором форма приходила к пользователю, в том же она отправлялась и обратно, но уже с заполненными полями. Бэкенд-разработчики точно знали какой набор данных им следует ожидать, всё было легко и предсказуемо. С широким распространением JS всё изменилось: сегодня уже никого не удивляет поведение приложения, при котором форма приходит с одним набором полей, а отправляется с совершенно иным, когда громоздкие формы имеют в своём составе небольшие динамические подформы, которые независимо от основной могут отправляться на сервер для обработки, когда выбранные файлы загружаются в фоновом режиме, в то время как пользователь заполняет остальную часть формы. Таким образом, всё большее количество логики переносится на сторону клиента, и это отлично, в первую очередь, конечно же, для пользователя. Для разработчика процесс работы с формами несколько усложнился. Но как бы тяжело ему не было, игнорировать развитие технологий сегодня невозможно, поэтому необходимо уметь эффективно их использовать.

Бэкенд против Фронтенда

Мы постоянно стремимся к автоматизации всего, с чем нам приходится работать, особенно рутинных задач, при этом пытаемся привнести в эти процессы некий порядок. Поэтому многих разработчиков несколько пугает динамичность на клиентский стороне, которая часто воспринимается ими как неконтролируемый хаос. Можно подумать, что у фронтенд-разработчиков развязаны руки, и они могут творить подобно художникам и скульпторам, их действия ничем не ограничены, а нам потом разбирать на сервере полёты их фантазии. Нередко так и случается, но это ошибочный, тупиковый путь. Это можно сравнить со schemaless-хранилищами данных: никто вас не ограничивает жёсткой структурой хранения данных, каждый из разработчиков в рамках одного проекта может придумать свой формат хранения, потом поменять его в зависимости от настроения, что в конечном счёте, скорее всего, приведёт к печальным последствиям. Если же вы ожидаете от своего продукта гибкости, легкой расширяемости и динамичного развития, вам необходимо будет придерживаться определённых правил, которые помогут поддерживать порядок в вашем приложении. То же самое вы в праве требовать и от фронтенд-разработчиков – творите, но придерживайтесь правил.

Итак, что вам, как бэкенд-разработчику, необходимо понять и принять:

  1. Перестаньте бояться динамики на серверной стороне.
    Мир и технологии не стоят на месте, и если вы не будете успевать под них подстраиваться, вы проиграете. Сегодня динамичность — это неотъемлемая часть нашей жизни, и вам придётся с этим смириться, хотите вы этого или нет. Теперь при работе с формами необходимо ориентироваться не только и не столько на заранее определенную разработчиком жёсткую структуру полей, сколько на пришедшие от пользователей данные.
  2. Не вините во всём фронтенд-разработчиков.
    Установите в компании, команде, проекте правила, и тогда у фронтенд-разработчиков будет не меньшая ответственность при работе с формами чем у вас. А ещё лучше, если кроме правил между всеми разработчиками будут доверительные отношения, а все решения будут приниматься в сотрудничестве.

Отправляем форму

Отлично, мы каким-то образом сгенерировали HTML для некоторой формы и отправили её пользователю. Заполнив поля и, возможно, изменив структуру формы, пользователю необходимо отправить её на сервер для обработки. Каким образом он может это сделать? Есть разные способы, большинство из которых потребует выполнения скриптов. Рассмотрим основные:
  1. Нажатие на кнопку отправки формы.
  2. Вызов метода submit у объекта формы.
  3. Сериализация полей формы.
  4. Создание и формирование произвольного запроса.

Способы в списке расположены в порядке возрастания прикладываемых фронтенд-разработчиком усилий, необходимых для отправки формы на сервер. Также можно условно разделить их на две группы: первые два способа составляют группу, в которой формированием и отправкой запроса занимается браузер, вторая группа включает последние два способа, при которых эти действия выполняет JS.

Пусть работает браузер

Для начала рассмотрим первую группу, оба способа которой мало чем отличаются друг от друга. В этом случае всю работу и ответственность на себя берёт браузер пользователя, причем действует он достаточно прямолинейно:

Source: habrahabr.ru

Похожие публикации:

  1. Систематизация Хранения Данных
  2. Безопасность Хранения Данных
  3. Алгоритмы Хранения Данных
  4. Способы Хранения Данных