Phoenix allows form submissions through data attributes: data-to, data-method and data-csrf.
That comes from the Phoenix.HTML library's little JS snippet:
function handleClick(element, targetModifierKey) {
var to = element.getAttribute("data-to"),
method = buildHiddenInput("_method", element.getAttribute("data-method")),
csrf = buildHiddenInput("_csrf_token", element.getAttribute("data-csrf")),
form = document.createElement("form"),
submit = document.createElement("input"),
target = element.getAttribute("target");
form.method = (element.getAttribute("data-method") === "get") ? "get" : "post";
form.action = to;
form.style.display = "none";
if (target) form.target = target;
else if (targetModifierKey) form.target = "_blank";
form.appendChild(csrf);
form.appendChild(method);
document.body.appendChild(form);
// Insert a button and click it instead of using `form.submit`
// because the `submit` function does not emit a `submit` event.
submit.type = "submit";
form.appendChild(submit);
submit.click();
}
The core logic that matters to us is as follows:
It uses the data-to as the action.
It builds two hidden inputs for "_method" and "_csrf_token".
In order for us to handle that, we reproduce some of the same logic. We pull the to, method, and csrf_token values from the element.
Thus, our Static logic is now able to handle these types of form submissions. There's an open question whether or not we should support those in LiveView. It seems like an odd use case. Most people would use a regular form submission (if they don't want to use LiveView) or a LiveView form. So, for now, we don't introduce the same logic in Live.
NOTE
Unlike other code, supporting this means users can have tests that pass when production is broken!!! (for example, if they forget to put the Phoenix.HTML.js in the app).
That's not ideal, but it seems like a worthwhile trade-off while Phoenix supports those forms as first-class behavior. Otherwise, we cannot test those types of form submissions -- which are still standard enough that Phoenix generators come with them out of the box.
What changed?
Phoenix allows form submissions through data attributes:
data-to
,data-method
anddata-csrf
.That comes from the
Phoenix.HTML
library's little JS snippet:The core logic that matters to us is as follows:
data-to
as the action.In order for us to handle that, we reproduce some of the same logic. We pull the
to
,method
, andcsrf_token
values from the element.Thus, our
Static
logic is now able to handle these types of form submissions. There's an open question whether or not we should support those in LiveView. It seems like an odd use case. Most people would use a regular form submission (if they don't want to use LiveView) or a LiveView form. So, for now, we don't introduce the same logic inLive
.NOTE
Unlike other code, supporting this means users can have tests that pass when production is broken!!! (for example, if they forget to put the Phoenix.HTML.js in the app).
That's not ideal, but it seems like a worthwhile trade-off while Phoenix supports those forms as first-class behavior. Otherwise, we cannot test those types of form submissions -- which are still standard enough that Phoenix generators come with them out of the box.