Error helper `error_tag/2` deprecated?

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.

Yes, that tracks!

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.

Awfully off topic, but would you ever say “yes” to being on Lex Fridman’s podcast?

N.B., I have no ties to him. But I like the idea of being able to tune into a long form, uncut interview.

Sure! My arm appreciates as many breaks as possible, especially long ones.

It was defined as follows:

	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.