Подтвердить что ты не робот

Неправильно хранить временные данные в скрытом элементе?

В одном из интервью, когда я присутствовал, меня попросили создать одну из функций java script, в которой, как мне говорили, была создана одна форма (например, имя, фамилия, адрес электронной почты, возраст) и один список (на самом деле листинг был видом другой формы, хранящей несколько записей) ниже этой формы. При отправке этой формы в список была добавлена ​​одна новая строка. Однако можно удалить любую ранее добавленную строку списка. и после добавления удаления, наконец, нужно сохранить это окончательное состояние листинга. (Тип изображения и сценарии на стороне сервера входят в картину)

Итак, что я сделал, On Form submit, добавив новую строку <tr> в таблицу листинга, в то же время я сериализую все данные формы, кроме кнопки отправки, используя сериализацию jQuery и сохраняя ее в одном скрытом элементе формы листинга.

При удалении строки списка я удалял строку <tr> вместе с соответствующим скрытым элементом для той же строки.

Все работали отлично, без ошибок. Но интервьюер спросил меня, что "подход, который я использовал (скрытые элементы), был действительно прав?".

Я ответил, я мог бы использовать json? но не мог взломать интервью. Поэтому я хочу знать, что лучше всего подходит для хранения данных в таких условиях?

4b9b3361

ОТВЕТЫ

Ответ 1

Другим подходом для клиентской стороны является сохранение списка объектов по отдельности и сохранение только ссылки на каждый элемент внутри свойства вашего элемента DOM. Этот подход очень похож на то, что предоставляет jQuery $.fn.data() и имеет следующие преимущества:

  • Вам не нужно сериализовать что-либо, данные остаются в его собственном формате; следует сказать, что вы могли бы достичь этого, добавив свойство также.

  • Все ваши данные хранятся в одном месте, а не разбросаны по DOM.

Это пример реализации:

(function(ns) {

var entries = {},
entryId = 1;

ns.Entries = {
   addEntry: function(data) {
     entries[entryId] = data;
     return entryId++;
   },
   getEntryById: function(id) {
     return entries[id] || null;
   }
};

}(this));

Вызов Entries.addEntry возвращает идентификатор, который вы можете сохранить в одном из свойств элемента DOM:

tr.entryId = Entries.addEntry(data);

Позже вы можете использовать это свойство entryId, чтобы найти соответствующие данные в списке записей и использовать его.

var data = Entries.getEntryById(tr.entryId);

Демо

Конечно, эта конкретная функциональность также может быть решена на стороне сервера с помощью сеансов.

Ответ 2

Благодаря HTML5 теперь у нас есть возможность встраивать атрибуты пользовательских данных во все элементы HTML. Эти новые атрибуты пользовательских данных состоят из двух частей:

  • Имя атрибута Имя атрибута данных должно иметь длину не менее одного символа и должно иметь префикс "data-". Он не должен содержать заглавных букв.
  • Значение атрибута Значение атрибута может быть любой строкой.

Используя этот синтаксис, мы можем добавить данные приложения к нашей разметке, как показано ниже:

<ul id="vegetable-seeds">
  <li data-spacing="10cm" data-sowing-time="March to June">Carrots</li>
  <li data-spacing="30cm" data-sowing-time="February to March">Celery</li>
  <li data-spacing="3cm" data-sowing-time="March to September">Radishes</li>
</ul>

Теперь мы можем использовать эти сохраненные данные на наших сайтах JavaScript, чтобы создать более богатый, более привлекательный пользовательский интерфейс. Представьте себе, что, когда пользователь нажимает на овощ, в браузере открывается новый слой, в котором отображаются дополнительные интервалы между семенами и указаниями посева. Благодаря атрибутам данных, добавленным к нашим элементам <li>, мы можем теперь отображать эту информацию мгновенно, не беспокоясь о любых вызовах Ajax и не требуя каких-либо запросов на серверную базу данных.

источник: HTML5 Doctor

Есть другие методы, на которые я верю.

Ответ 3

Фактически вместо использования скрытых элементов вы можете добавлять данные в элементы html с помощью jQuery. Это лучший подход, чтобы сделать ваши данные немного менее очевидными/прямыми для пользователей. Проверьте данные() в jQuery.

Ответ 4

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

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

Ответ 5

Проблема с решениями, которые "просто работают", заключается в том, что они недостаточно абстрактны и поэтому, как правило, вызывают проблемы в будущем. Рассмотрим ваш пример; если вы решите сохранить временные данные в локальном хранилище (чтобы пользователи могли закрыть браузер и вернуться к нему позже), вам придется переписать, как вы храните свои данные. Если вы сохранили его в переменной, вы сможете добавить "Сохранить в локальное хранилище" так же легко, как функциональность "Отправить на сервер" или "Передать любой другой функции". Ваш подход "скрытого элемента" должен быть переписан для любых целей, кроме публикации для обслуживания.

Ответ 6

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

Конечно, сохранение данных в скрытом поле является допустимым методом.

Ответ 7

Написав представленные данные в форму и снова прочитав ее, вы связали эти два элемента вместе - они, как говорят, тесно связаны.

Какое слово произойдет, если еще одно требование появилось для отображения ранее представленных данных в таблице? Или разместить форму на отдельной странице?

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

Ответ 8

Я не буду отвечать на ваш вопрос напрямую, но сосредоточусь на собеседовании и методе, который вы выбрали.

Я бы сказал, что вы выбрали неправильный путь и хорошо известную ИТ-компанию, на которую вы применили это решение, потому что могут иметь проблемы.

Вы выбрали способ хранения всего на клиентской стороне, но не должны! Так как ваш клиент может потерять много данных таким образом, потому что представьте себе случай, когда ваша листинговая форма никогда не будет отправлена? Пользователь просто забудет поразить send (никогда не доверяйте пользователю!). Затем вы теряете все... весь ход вашей работы... и пусть говорят, что вы уже добавили 50 листинговых элементов...

Также добавление таких элементов может привести к сокращению срока действия вашего сеанса (без запросов на сервер), и никакие данные не будут сохранены, так как пользователю придется снова войти в систему. И вам придется справиться с этим, или вы потеряете все!

Извините за восклицательные знаки, но я думаю, что данные имеют решающее значение (особенно для вашего клиента), поэтому никогда не предлагают решения, которые могут заставить клиента как-то потерять его.

Итак:

Неплохо хранить данные в HTML-элементах, но вам нужно применять это решение очень осторожно.