I have been reading up on using forms in LiveView. I come across the error_tag/2 function often (for example in this 2022 article by Sophie DeBenedetto) but in the latest official documentation I cannot find any mention of it.
error_tag was always part of your app. So you can just add something that does the same to your app. IIRC it was just an error string wrapped in a span tag.
Yes, I believe it used to be injected into any project scaffolded with mix new, inside ErrorHelpers.ex. I reckon that it has been removed from the mix new boilerplate code, in favour of the error/1 function component that’s part of the core components? Which also basically also just a wrapper.
It’d be nice if all bloggers led off with the versions of stack they’re using
The 1.7 release at the start of 2023 was a big change: components and verified routes involved a lot of changes to the view templates. So you’re going to need to account for that when reading any blog from 2022 or earlier. The official changelog is a great source of lots of information about those changes.
use Phoenix.HTML
@doc """
Generates tag for inlined form input errors.
"""
def error_tag(form, field) do
Enum.map(
Keyword.get_values(form.errors, field), fn error ->
content_tag(
:span,
translate_error(error),
class: "invalid-feedback",
phx_feedback_for: input_name(form, field)
)
end
)
end
So… I now have error_tag/2 all over my application. Wondering if I could easily change this to use the latest approach, including translations and w/o replacing all those error_tags scattered across large number of files/forms. How would you experts do it? Any caveats/gotchas to expect? Yes, I know there’s the “shim”, utilising which should do the trick I presume, but I think of taking a step towards the LiveView 1.0.x approach, while still w/o replacing all those occurrences.
Replacing this shouldn’t be much of a problem. Most functions in Phoenix.HTML (including content_tag) return data for which the Phoenix.HTML.Safe protocol is implemented. The data you get from ~H sigils also has a implementation of that protocol. This error_tag function returns a list of safe data, but the protocol for implementation for lists just iterates nested safe data, so returning the results of a single ~H should generally also be fine.
You might have places in your codebase, which depend on the return value being a list or even dig deeper into the results, but I’d argue those would be worth fixing and I wouldn’t expect many of such in a codebase.
I don’t recall ever using it in a deeply unusual way. Differences might be mostly (if not only) in the placement I believe. Either right next/under the corresponding input or grouped into errors summary boxes. Shall have a stab at replacing the implementation then and see how it goes, thank you.