В рельсах использовать помощники формы или нет?

Я думаю, что помощники форм - это отражение принципа СУХОЙ (не повторяйся). Вместо того, чтобы писать один и тот же код для выполнения аналогичных задач, лучше всего создать помощника формы, который позволяет повторно использовать этот код. Таким образом, если вам нужно внести изменения или исправить, вам нужно будет сделать это только в одном месте. Это также помогает сделать ваш код более компактным и читаемым, чтобы преобразовать сложное действие в помощник формы. То же самое верно и для частичных представлений, хотя частичные представления, как правило, инкапсулируют более сложную разметку, чем помощник формы.

Помощники форм особенно полезны, позволяя рельсам обрабатывать создание форм на основе вашей модели. Приведем пример документации API:

Следующий код

<% form_for :person, @person, :url => { :action => "create" } do |f| %>
  <%= f.text_field :first_name %>
  <%= f.text_field :last_name %>
  <%= submit_tag 'Create' %>
<% end %>

генерирует этот HTML

<form action = "/persons/create" method = "post">
  <input id = "person_first_name" name = "person[first_name]" size = "30" type = "text" />
  <input id = "person_last_name" name = "person[last_name]" size = "30" type = "text" />
  <input name = "commit" type = "submit" value = "Create" />
</form>

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

Определите производительность. Ваше выступление или приложения? Предположим, у вас есть один и тот же фрагмент кода rhtml, распределенный по вашим представлениям. Скажем, он у вас есть в тысячах мест. Может, у вас даже не получилось, что точно одинаково везде. Теперь ваш клиент хочет изменить это (возможно, другой порядок представления или что-то в этом роде). Вам понадобится время, чтобы сделать это во всех представлениях, верно? И скорее всего, вы не поймете это правильно с первого раза. Скорее всего, вы будете получать отчеты об ошибках в течение многих лет о местах, которые вы пропустили, чтобы изменить.

Заказчик в конечном итоге будет дорого платить за эту «производительность». Может, сотни рабочих часов. Может быть, десятки тысяч, если принципиально избегать принципа СУХОЙ. Вместо этого подумайте обо всех серверах и всей оперативной памяти, которую она могла бы купить для этих рабочих часов. Если бы она потратила все это на оборудование, ее приложение могло бы работать в сотни раз быстрее. Подумайте обо всех забавных вещах, с которыми вы могли бы работать, вместо того, чтобы обезопасить себя от изменения фрагментов HTML.

Это кажется хорошим, когда разработчик имеет одно и то же имя для класса, id и не имеет значения для поля ввода, если ему нужен другой идентификатор имени, а также значение, тогда он должен написать <% = text_field_tag ​​"name",: value => "value",: id => "id",: class => "" class%>, а для того же html может быть <input type = "text" value = "value" class = "class" name = "name" id = "id" /> теперь подумайте о накладных расходах 1., оцените первый помощник в html 2. теперь также учитывайте длину этого помощника, который мы также должны написать:, => 3. иногда вы забываете использовать: или по ошибке поэтому я думаю, что в этом случае мы предпочитаем HTML И одна вещь, если ваш сервер получает много запросов, он будет слишком занят, и время ответа будет увеличено, потому что <% =%> должен выполнить

Это очень старый вопрос, но я новичок на рельсах. Я бы сказал, что вместо того, чтобы писать это

<label class = "input-group__label" for = "email">Email</label>
<input class = "input-group__field" id = "email" type = "email" name = "email" placeholder = "e.g. [email protected]">

написать то же самое с помощью таких помощников по рельсам

<%= label_tag 'email', nil, class: 'input-group__label' %>
<%= email_field_tag "email", nil, placeholder: "e.g. [email protected]", class: "input-group__field" %>

в form_tag это очень СУХИЙ способ делать вещи. Читаемость лучше в первом. Это может понять каждый. Знания рельсов не требуются. Специфические теги Rails не оцениваются и не конвертируются (небольшое увеличение производительности). Количество кода такое же. Если бы это было внутри form_for, который создает форму из модели, я понимаю использование специальных тегов и помощников rails. Это имеет смысл. Но я не вижу реального преимущества использования помощников rails для простого html, как в примере выше.