|
1 | 1 | # Actions
|
2 | 2 |
|
3 |
| - |
| 3 | +The `action` component can be used to trigger asynchronous requests from for example a button click or any other html markup. The `action` components let's us wrap content which is then clickable and triggers a request with the configured request method to the configured path and with the given params (giving you the ability to add whatever params you want) and let's us react to the server response. It can distinguish between a successful and failed response and emit events, transition somewhere, completely redirect and more for both. You only need to configure it according to your needs. |
| 4 | + |
| 5 | +## Usage |
| 6 | + |
| 7 | +Let's assume we want a delete button on our products show page in the management app. Deleting a product would require us to send a DELETE request to the `product_path(product)`. In the example below, clicking the "Delete" button will trigger an asynchronous DELETE request to the `products_path(id)` with params `foo: :bar`. If successful the action component will trigger a transition to the path the controller redirected us to. If the request failed it will emit the "deletion-failed" event. |
| 8 | + |
| 9 | +We recommend defining the expected hash parameter for `action` components in a method for better readability. |
| 10 | + |
| 11 | +```ruby |
| 12 | +def response |
| 13 | + action action_config do |
| 14 | + button text: 'Delete' |
| 15 | + end |
| 16 | +end |
| 17 | + |
| 18 | +def action_config |
| 19 | + { |
| 20 | + path: product_path(product), |
| 21 | + method: :delete, |
| 22 | + params: { |
| 23 | + foo: :bar |
| 24 | + }, |
| 25 | + sucess: { |
| 26 | + transition: { |
| 27 | + follow_response: true |
| 28 | + } |
| 29 | + }, |
| 30 | + failure: { |
| 31 | + emit: 'deletion-failed' |
| 32 | + } |
| 33 | + } |
| 34 | +end |
| 35 | +``` |
| 36 | + |
| 37 | +**Basic confirm dialog** |
| 38 | + |
| 39 | +By adding `confirm: true` inside the config, the `action` component will show a [browser-native confirm dialog](https://developer.mozilla.org/en-US/docs/Web/API/Window/confirm) before performing the request. |
| 40 | +When specified, a [browser-native confirm dialog](https://developer.mozilla.org/en-US/docs/Web/API/Window/confirm) is shown before the action is actually performed. The action only is performed after the user confirms. The action is not performed if the user declines to confirm dialog. |
| 41 | + |
| 42 | +**Success and failure behavior** |
| 43 | + |
| 44 | +We can customize the success and failure behavior of an `action` component by specifiyng the `:success` or `:failure` key with a hash as value. The value hash can contain different keys for different behavior. |
| 45 | + |
| 46 | +* use `:emit` inside it to emit an event for success or failed responses. |
| 47 | +* use `:transition` to transition to another page. Either specifiyng a hash containing a path and optional params or a hash with `follow_response: true` in order to follow the redirect of the response. |
| 48 | +* use `:redirect` with a hash containing a path and params or `follow_response: true` to redirect the browser to the target. Be aware that this will trigger a full website reload as it is a redirect and no transition. |
| 49 | + |
| 50 | +You can also combine `:emit` and one of `:transition`, `:redirect` if wanted. |
| 51 | + |
| 52 | +If you want to know all details about the `action` component, like how you can delay it, what events it emits or how exactly the response behavior can be customized, checkout it's [api documentation](/docs/api/100-components/action.md) |
0 commit comments