I think virtual fields are a good use case for it,
For instance:

defimpl Jason.Encoder, for: WhateverSchema do
  def encode(struct, opts) do
    struct
    |> Map.put(:avatar, RunTimeSettings.get_url_for(struct))
    # |> maybe_trim_private_fields()
    |> Jason.Encode.map(opts)
  end
end

Personally, if the full url is the only thing that makes sense for the client(s), I replace the field itself with the valid url, if the client needs/can use the field value for something, I define a virtual field and then populate that instead.

Do you need the data on the schema itself, or is it sufficient to include the URL when the struct is serialized to JSON? In the latter case, @amnu3387’s solution will do exactly what you need.

In the former case, things are more complicated - invoking route helpers from inside schemas will mean a circular dependency between the data layer and the Phoenix layer.

That makes sense – is :avatar a virtual field in that example? I haven’t tested that, but is the virtual field even necessary if you are just putting a field into a map?

And I guess for thoroughness, I would love to see an example of how to add something to the schema. E.g. the class accessor example of having a first_name and last_name field in the database, and then having a “virtual” field for full_name that concatenates the two together.