Commit Graph

8 Commits

Author SHA1 Message Date
Javi Martín
f52a86b465 Apply (but don't add) Capybara/SpecificMatcher rule
This rule was added in rubocop-rspec 2.12.0, and we were already
following it most of the time.

However, the rule isn't working correctly in some cases, such as input
selectors, so we aren't enabling it.
2023-09-06 19:00:56 +02:00
Javi Martín
b8ed81c5b8 Simplify setting up admin component tests 2023-08-30 14:46:34 +02:00
Javi Martín
5311daadfe Use a button for non-GET table actions
Links acting like buttons have a few disadvantages.

First, screen readers will announce them as "links". Screen reader users
usually associate links with "things that get you somewhere" and buttons
with "things that perform an action". So when something like "Delete,
link" is announced, they'll probably think this is a link which will
take them to another page where they can delete a record.

Furthermore, the URL of the link for the "destroy" action might be the
same as the URL for the "show" action (only one is accessed with a
DELETE request and the other one with a GET request). That means screen
readers could announce the link like "Delete, visited link", which is
very confusing.

They also won't work when opening links in a new tab, since opening
links in a new tab always results in a GET request to the URL the link
points to.

Finally, submit buttons work without JavaScript enabled, so they'll work
even if the JavaScript in the page hasn't loaded (for whatever reason).

For all these reasons (and probably many more), using a button to send
forms is IMHO superior to using links.

There's one disadvantage, though. Using `button_to` we create a <form>
tag, which means we'll generate invalid HTML if the table is inside
another form. If we run into this issue, we need to use `button_tag`
with a `form` attribute and then generate a form somewhere else inside
the HTML (with `content_for`).

Note we're using `button_to` with a block so it generates a <button>
tag. Using it in a different way the text would result in an <input />
tag, and input elements can't have pseudocontent added via CSS.

The following code could be a starting point to use the `button_tag`
with a `form` attribute. One advantage of this approach is screen
readers wouldn't announce "leaving form" while navigating through these
buttons. However, it doesn't work in Internet Explorer.

```
ERB:

<% content_for(:hidden_content, form_tag(path, form_options) {}) %>
<%= button_tag text, button_options %>

Ruby:

def form_id
  path.gsub("/", "_")
end

def form_options
  { id: form_id, method: options[:method] }
end

def button_options
  html_options.except(:method).merge(form: form_id)
end

Layout:

<%= content_for :hidden_content %> # Right before the `</body>`
```
2021-09-20 20:27:37 +02:00
Javi Martín
4cbf945228 Infer type for component specs automatically 2021-09-08 12:39:36 +02:00
Javi Martín
6df7f7d052 Simplify changing controllers in component tests 2021-08-10 15:00:26 +02:00
Javi Martín
c66a5a30ef Allow using table actions in different namespaces
This way we can reuse it in sections like SDGManagement and URLs will be
automatically generated as expected.
2021-01-14 17:35:38 +01:00
Javi Martín
c5a6ee74c4 Fix component specs using "within"
These specs were passing because the `within` method does not work in
components specs. We have to use `page.find` instead.
2021-01-09 15:48:12 +01:00
Javi Martín
7cb0a4135b Extract component for admin officers table
This way we can remove duplication and simplify the code in the view.

Note we're not using the "within" method in the tests to access a row,
because it doesn't seem to work in components tests when passing the
`text:` option.
2020-10-21 13:19:52 +02:00