2021-10-08 21:36:49 -04:00
* Support `fields model: [@nested, @model]` the same way as `form_with model:
[@nested, @model ]`.
*Sean Doyle*
2021-10-08 14:50:02 -04:00
* Infer HTTP verb `[method]` from a model or Array with model as the first
argument to `button_to` when combined with a block:
```ruby
button_to(Workshop.find(1)){ "Update" }
#=> < form method = "post" action = "/workshops/1" class = "button_to" >
#=> < input type = "hidden" name = "_method" value = "patch" autocomplete = "off" / >
#=> < button type = "submit" > Update< / button >
#=> < / form >
button_to([ Workshop.find(1), Session.find(1) ]) { "Update" }
#=> < form method = "post" action = "/workshops/1/sessions/1" class = "button_to" >
#=> < input type = "hidden" name = "_method" value = "patch" autocomplete = "off" / >
#=> < button type = "submit" > Update< / button >
#=> < / form >
```
*Sean Doyle*
2021-10-08 12:35:16 -04:00
* Support passing a Symbol as the first argument to `FormBuilder#button` :
```ruby
form.button(:draft, value: true)
# => < button name = "post[draft]" value = "true" type = "submit" > Create post< / button >
form.button(:draft, value: true) do
content_tag(:strong, "Save as draft")
end
# => < button name = "post[draft]" value = "true" type = "submit" >
# < strong > Save as draft< / strong >
# < / button >
```
*Sean Doyle*
Introduce `field_name` view helper
The `field_name` helper and corresponding `FormBuilder#field_name`
method provide an Action View-compliant way of overriding a form field
element's `[name]` attribute (similar to `field_id` and
`FormBuilder#field_id` introduced in rails/rails#40127[][]).
```ruby
text_field_tag :post, :title, name: field_name(:post, :title, :subtitle)
# => <input type="text" name="post[title][subtitle]">
text_field_tag :post, :tag, name: field_name(:post, :tag, multiple: true)
# => <input type="text" name="post[tag][]">
form_for @post do |f|
f.field_tag :tag, name: f.field_name(:tag, multiple: true)
# => <input type="text" name="post[tag][]">
end
```
[rails/rails#40127]: https://github.com/rails/rails/pull/40127
2021-10-08 12:52:53 -04:00
* Introduce the `field_name` view helper, along with the
`FormBuilder#field_name` counterpart:
```ruby
form_for @post do |f|
f.field_tag :tag, name: f.field_name(:tag, multiple: true)
# => < input type = "text" name = "post[tag][]" >
end
```
*Sean Doyle*
Execute `field_error_proc` within view
Instead of treating it as an anonymous block, execute the
`ActionView::Base.field_error_proc` within the context of the
`ActionView::Base` instance.
This enables consumer applications to continue to override the proc as
they see fit, but frees them from declaring templating logic within a
`config/initializers/*.rb`, `config/environments/*.rb` or
`config/application.rb` file.
This makes it possible to replace something like:
```ruby
config.action_view.field_error_proc = proc do |html_tag, instance|
<<~HTML.html_safe
#{html_tag}
<span class="errors">#{instance.error_message.to_sentence}</span>
HTML
end
```
With inline calls to Action View helpers like:
```ruby
config.action_view.field_error_proc = proc do |html_tag, instance|
safe_join [ html_tag, tag.span(instance.error_message.to_sentence, class: "errors") ]
end
```
Or with a view partial rendering, like:
```ruby
config.action_view.field_error_proc = proc do |html_tag, instance|
render partial: "application/field_with_errors", locals: { html_tag: html_tag, instance: instance }
end
```
Then, elsewhere in `app/views/application/field_with_errors.html.erb`:
```erb
<%= html_tag %>
<span class="errors"><%= instance.error_message.to_sentence %></span>
```
2021-07-11 12:30:45 -04:00
* Execute the `ActionView::Base.field_error_proc` within the context of the
`ActionView::Base` instance:
```ruby
config.action_view.field_error_proc = proc { |html| content_tag(:div, html, class: "field_with_errors") }
```
*Sean Doyle*
2021-10-09 15:40:38 -04:00
* Add support for `button_to ..., authenticity_token: false`
```ruby
button_to "Create", Post.new, authenticity_token: false
# => < form class = "button_to" method = "post" action = "/posts" > < button type = "submit" > Create< / button > < / form >
button_to "Create", Post.new, authenticity_token: true
# => < form class = "button_to" method = "post" action = "/posts" > < button type = "submit" > Create< / button > < input type = "hidden" name = "form_token" value = "abc123..." autocomplete = "off" / > < / form >
button_to "Create", Post.new, authenticity_token: "secret"
# => < form class = "button_to" method = "post" action = "/posts" > < button type = "submit" > Create< / button > < input type = "hidden" name = "form_token" value = "secret" autocomplete = "off" / > < / form >
```
*Sean Doyle*
Support `<form>` elements without `[action]`
Some background
---
By default, when a `<form>` is declared without an `[action]` attribute,
browsers will encode a `<form>`'s fields into the _current_ URL.
This can be useful for a `<form method="get">` that operates on the
current page. For example, when filtering search results, a form that
sorts:
```html
<form method="get">
<button name="sort" value="desc">Most to least</button>
<button name="sort" value="asc">Least to most</button>
</form>
```
can operate on a page that is filtered in another way by merging the
`?sort=asc` or `?sort=desc` values _into_ the existing page, which might
have the `?q=...` string set elsewhere.
The problem
---
Prior to this commit, none of the `<form>` construction variations
supported declaring a `<form>` without an `[action]` attribute.
`form_with`, `form_for`, and `form_tag` all default to `url_for({})`
when a `url:` or `action:` option is omitted.
The solution
---
Treat `url: false`, or `action: false` as an escape hatch to signal to
Action View that we don't need to transform the `model:` option or
argument into a Rails route.
Similarly, when calling `button_to` with `false` as the URL options
arguments will construct a `<form>` element without an `[action]`
attribute.
2021-04-21 15:24:42 -04:00
* Support rendering `<form>` elements _without_ `[action]` attributes by:
* `form_with url: false` or `form_with ..., html: { action: false }`
* `form_for ..., url: false` or `form_for ..., html: { action: false }`
* `form_tag false` or `form_tag ..., action: false`
* `button_to "...", false` or `button_to(false) { ... }`
*Sean Doyle*
2021-10-28 00:51:20 -04:00
* Add `:day_format` option to `date_select`
date_select("article", "written_on", day_format: ->(day) { day.ordinalize })
# generates day options like < option value = "1" > 1st</ option > \n< option value = "2" > 2nd</ option > ...
*Shunichi Ikegami*
2021-09-21 18:54:48 -04:00
* Allow `link_to` helper to infer link name from `Model#to_s` when it
2021-05-15 20:16:07 -04:00
is used with a single argument:
link_to @profile
#=> < a href = "/profiles/1" > Eileen< / a >
2021-09-21 18:54:48 -04:00
This assumes the model class implements a `to_s` method like this:
2021-05-15 20:16:07 -04:00
2021-09-21 18:54:48 -04:00
class Profile < ApplicationRecord
2021-05-15 20:16:07 -04:00
# ...
def to_s
name
end
end
Previously you had to supply a second argument even if the `Profile`
model implemented a `#to_s` method that called the `name` method.
link_to @profile , @profile .name
#=> < a href = "/profiles/1" > Eileen< / a >
*Olivier Lacan*
2021-09-16 14:50:54 -04:00
* Support svg unpaired tags for `tag` helper.
tag.svg { tag.use('href' => "#cool-icon") }
# => < svg > < use href = "#cool-icon" > < / svg >
*Oleksii Vasyliev*
2021-09-15 18:22:51 -04:00
2021-09-20 17:35:12 -04:00
## Rails 7.0.0.alpha2 (September 15, 2021) ##
* No changes.
2021-09-15 17:55:08 -04:00
## Rails 7.0.0.alpha1 (September 15, 2021) ##
2021-08-25 20:28:19 -04:00
* Improves the performance of ActionView::Helpers::NumberHelper formatters by avoiding the use of
exceptions as flow control.
*Mike Dalessio*
2021-08-24 11:55:37 -04:00
* `preload_link_tag` properly inserts `as` attributes for files with `image` MIME types, such as JPG or SVG.
*Nate Berkopec*
2021-08-05 20:44:29 -04:00
* Add `weekday_options_for_select` and `weekday_select` helper methods. Also adds `weekday_select` to `FormBuilder` .
*Drew Bragg* , *Dana Kashubeck* , *Kasper Timm Hansen*
2021-08-05 10:03:08 -04:00
* Add `caching?` helper that returns whether the current code path is being cached and `uncacheable!` to denote helper methods that can't participate in fragment caching.
2021-06-02 18:29:59 -04:00
*Ben Toews* , *John Hawthorn* , *Kasper Timm Hansen* , *Joel Hawksley*
2021-08-07 12:53:10 -04:00
* Add `include_seconds` option for `time_field` .
2021-03-22 13:38:15 -04:00
< %= form.time_field :foo, include_seconds: false %>
# => < input value = "16:22" type = "time" / >
Default includes seconds:
< %= form.time_field :foo %>
# => < input value = "16:22:01.440" type = "time" / >
This allows you to take advantage of [different rendering options ](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time#time_value_format ) in some browsers.
*Alex Ghiculescu*
2021-07-12 12:16:25 -04:00
* Improve error messages when template file does not exist at absolute filepath.
2021-07-11 22:04:52 -04:00
*Ted Whang*
2021-02-26 13:37:35 -05:00
* Add `:country_code` option to `sms_to` for consistency with `phone_to` .
*Jonathan Hefner*
2021-03-22 05:25:49 -04:00
* OpenSSL constants are now used for Digest computations.
*Dirkjan Bussink*
2020-11-25 17:47:25 -05:00
* The `translate` helper now passes `default` values that aren't
translation keys through `I18n.translate` for interpolation.
*Jonathan Hefner*
2021-04-12 00:30:43 -04:00
* Adds option `extname` to `stylesheet_link_tag` to skip default
`.css` extension appended to the stylesheet path.
Before:
2021-07-20 21:08:08 -04:00
2021-04-12 00:30:43 -04:00
```ruby
stylesheet_link_tag "style.less"
# < link href = "/stylesheets/style.less.scss" rel = "stylesheet" >
```
After:
2021-07-20 21:08:08 -04:00
2021-04-12 00:30:43 -04:00
```ruby
stylesheet_link_tag "style.less", extname: false, skip_pipeline: true, rel: "stylesheet/less"
# < link href = "/stylesheets/style.less" rel = "stylesheet/less" >
```
*Abhay Nikam*
2021-02-16 13:20:21 -05:00
* Deprecate `render` locals to be assigned to instance variables.
*Petrik de Heus*
2021-01-26 19:33:12 -05:00
* Remove legacy default `media=screen` from `stylesheet_link_tag` .
*André Luis Leal Cardoso Junior*
2021-01-07 10:43:47 -05:00
* Change `ActionView::Helpers::FormBuilder#button` to transform `formmethod`
attributes into `_method="$VERB"` Form Data to enable varied same-form actions:
< %= form_with model: post, method: :put do %>
< %= form.button "Update" %>
< %= form.button "Delete", formmethod: :delete %>
< % end %>
< %# => < form action = "posts/1" >
=> < input type = "hidden" name = "_method" value = "put" >
=> < button type = "submit" > Update< / button >
=> < button type = "submit" formmethod = "post" name = "_method" value = "delete" > Delete< / button >
=> < / form >
%>
*Sean Doyle*
Consistently render `button_to` as `<button>`
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
2020-12-03 21:01:39 -05:00
* Change `ActionView::Helpers::UrlHelper#button_to` to *always* render a
`<button>` element, regardless of whether or not the content is passed as
2020-12-29 07:11:16 -05:00
the first argument or as a block.
Consistently render `button_to` as `<button>`
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
2020-12-03 21:01:39 -05:00
< %= button_to "Delete", post_path(@post), method: :delete %>
2021-03-22 13:38:15 -04:00
# => < form action = "/posts/1" > < input type = "hidden" name = "_method" value = "delete" > < button type = "submit" > Delete< / button > < / form >
Consistently render `button_to` as `<button>`
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
2020-12-03 21:01:39 -05:00
< %= button_to post_path(@post), method: :delete do %>
Delete
< % end %>
2021-03-22 13:38:15 -04:00
# => < form action = "/posts/1" > < input type = "hidden" name = "_method" value = "delete" > < button type = "submit" > Delete< / button > < / form >
Consistently render `button_to` as `<button>`
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
2020-12-03 21:01:39 -05:00
2020-12-29 07:11:16 -05:00
*Sean Doyle* , *Dusan Orlovic*
Consistently render `button_to` as `<button>`
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
2020-12-03 21:01:39 -05:00
2020-12-18 14:11:16 -05:00
* Add `config.action_view.preload_links_header` to allow disabling of
the `Link` header being added by default when using `stylesheet_link_tag`
and `javascript_include_tag` .
Consistently render `button_to` as `<button>`
Prior to this commit, the
[ActionView::Helpers::UrlHelper#button_to][button_to] helper rendered
`<input type="submit">` elements when passed its contents as a String
argument, and rendered `<button type="submit">` elements when passed its
contents as a block.
This difference is subtle, and might lead to surprises.
Additionally, a `<form>` element's submitter can encode a `name`/`value`
pairing, which will be submitted as part of the request. When
`button_to` renders an `<input type="submit">` element, the "button"
content is rendered as a `[value]` attribute, which prevents any
meaningful data from being encoded.
Since it's a single `<button>` or `<input type="submit">` within a
`<form>`, missing out on that opportunity to encode information might
not be a show stopper, but ensuring that a `<button>` element is
rendered _without_ a default `[value]` attribute enables applications to
encode additional information that can be accessed JavaScript as
`element.value`, instead of a workaround like
`element.getAttribute("data-value")`.
Support rendering `input` elements with button_to
---
To support the original behavior of `button_to` rendering `<input
type="submit">` elements when invoked _without_ a block, expose the
`app.config.button_to_generates_button_tag` configuration flag.
By default, it's set to `true` and ensures that all `button_to` calls
render `<button>` elements. To revert to the original behavior, set it
to `false`.
[button_to]: https://api.rubyonrails.org/v6.0/classes/ActionView/Helpers/UrlHelper.html#method-i-button_to
Co-authored-by: Dusan Orlovic <duleorlovic@gmail.com>
2020-12-03 21:01:39 -05:00
2020-12-18 14:11:16 -05:00
*Andrew White*
2020-12-10 12:38:11 -05:00
* The `translate` helper now resolves `default` values when a `nil` key is
specified, instead of always returning `nil` .
*Jonathan Hefner*
2020-12-08 19:12:51 -05:00
* Add `config.action_view.image_loading` to configure the default value of
the `image_tag` `:loading` option.
By setting `config.action_view.image_loading = "lazy"` , an application can opt in to
lazy loading images sitewide, without changing view code.
*Jonathan Hefner*
Declare ActionView::Helpers::FormBuilder#id
`ActionView::Helpers::FormBuilder#id`
---
Generate an HTML `id` attribute value.
Return the [`<form>` element's][mdn-form] `id` attribute.
```html+erb
<%= form_for @post do |f| %>
<%# ... %>
<% content_for :sticky_footer do %>
<%= form.button(form: f.id) %>
<% end %>
<% end %>
```
In the example above, the `:sticky_footer` content area will exist
outside of the `<form>` element. [By declaring the `form` HTML
attribute][mdn-button-attr-form], we hint to the browser that the
generated `<button>` element should be treated as the `<form>` element's
submit button, regardless of where it exists in the DOM.
[A similar pattern could be used for `<input>`
elements][mdn-input-attr-form] (or other form controls) that do not
descend from the `<form>` element.
`ActionView::Helpers::FormBuilder#field_id`
---
Generate an HTML <tt>id</tt> attribute value for the given field
Return the value generated by the <tt>FormBuilder</tt> for the given
attribute name.
```html+erb
<%= form_for @post do |f| %>
<%= f.label :title %>
<%= f.text_field :title, aria: { describedby: form.field_id(:title, :error) } %>
<span id="<%= f.field_id(:title, :error) %>">is blank</span>
<% end %>
```
In the example above, the <tt><input type="text"></tt> element built by
the call to <tt>FormBuilder#text_field</tt> declares an
<tt>aria-describedby</tt> attribute referencing the <tt><span></tt>
element, sharing a common <tt>id</tt> root (<tt>post_title</tt>, in this
case).
This method is powered by the `field_id` helper declared in
`action_view/helpers/form_tag_helper`, which is made available for
general template calls, separate from a `FormBuilder` instance.
[mdn-form]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form
[mdn-button-attr-form]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#attr-form
[mdn-input-attr-form]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-form
[mdn-aria-describedby]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-describedby_attribute
[w3c-wai]: https://www.w3.org/WAI/tutorials/forms/notifications/#listing-errors
2020-08-27 20:28:43 -04:00
* `ActionView::Helpers::FormBuilder#id` returns the value
of the `<form>` element's `id` attribute. With a `method` argument, returns
the `id` attribute for a form field with that name.
< %= form_for @post do |f| %>
< %# ... %>
< % content_for :sticky_footer do %>
< %= form.button(form: f.id) %>
< % end %>
< % end %>
*Sean Doyle*
* `ActionView::Helpers::FormBuilder#field_id` returns the value generated by
the FormBuilder for the given attribute name.
< %= form_for @post do |f| %>
< %= f.label :title %>
< %= f.text_field :title, aria: { describedby: f.field_id(:title, :error) } %>
< %= tag.span("is blank", id: f.field_id(:title, :error) %>
< % end %>
*Sean Doyle*
* Add `tag.attributes` to transform a Hash into HTML Attributes, ready to be
interpolated into ERB.
2020-11-28 05:01:15 -05:00
< input < % = tag . attributes ( type: :text , aria: { label: " Search " } ) % > >
# => < input type = "text" aria-label = "Search" >
*Sean Doyle*
2019-04-19 12:34:53 -04:00
2020-12-02 18:37:26 -05:00
Please check [6-1-stable ](https://github.com/rails/rails/blob/6-1-stable/actionview/CHANGELOG.md ) for previous changes.