This looks great! How about supporting this syntax:

defschema schema do
  required ...
end

I’d love to see the functionality of Goal incorporated into Ecto. Did you consider that? If so, there’s one thing to think about: the Goal schema seems to be controller-specific so it makes sense to have required, min, max, etc. as options. On the other hand Ecto schemas are reused across the changeset functions (each function has its own set of required/optional/validations). I still think it would make sense to support what Goal is using, maybe with a different macro (there’s schema and embedded_schema, so maybe validation_schema?).

required :uuid, :string, format: :uuid

optional :gender, :enum, values: ["female", "male", "non-binary"]

if the library is based on Ecto, then why not to use built-in types? I mean this

required :uuid, Ecto.UUID

optional :gender, Ecto.Enum, values: ["female", "male", "non-binary"]

Goal 0.1.3 released

I recently switched to LiveViews and found that I have the same need to validate incoming parameters as with JSON APIs. Since LiveViews depend on changesets for validation, I decided to expose the Goal.build_changeset(params, schema) function in the library.

I find using database Ecto.Schemas in LiveViews, like the examples in the LiveView docs do, a bit problematic because I often need fields that aren’t defined in the Ecto.Schema. Embedded schemas are great, but it’s a lot of boilerplate…

Plus, often my changesets have required fields like foreign keys that I cannot validate in the LiveView so the changeset is never valid; a state that I use in my forms to enable/disable form submit buttons.

Goal solves all that with a sweet syntax.

Using Goal for LiveViews is super easy:

defmodule MyApp.SomeLiveView do
  import Goal.Syntax

  def handle_event("validate", %{"some" => some_params}, socket) do
    changeset =
      some_params
      |> Goal.build_changeset(schema())
      |> Map.put(:action, :validate)

    {:noreply, assign(socket, :changeset, changeset)}
  end

  defp schema do
    defschema do
      required :id, :uuid
      required :name, :string, max: 20
      optional :age, :integer, min: 0, max: 120
      optional :gender, :enum, values: ["female", "male", "non-binary"]
      optional :address, :string

      optional :data, :map do
        required :color, :string
        optional :money, :decimal
        optional :height, :float
      end
    end
  end
end

Goal 0.2.0 released today!

This version contains some breaking, but very convenient changes to the library.

1. It adds the defparams macro which makes defining parameter validation schemas easier than before, because it encapsulates the schemas in a function that you can call elsewhere.
2. It adds conveniences like validate/1 and /2, and changeset/1 and /2 that can be like MySchema.validate(:new, params) and MySchema.changeset(:new, params)

Let’s take a look at the new defparams macro:

Example with a schema in a separate module

Define a schema in a separate module:

defmodule MyAppWeb.MySchema do
  use Goal

  defparams :create do
    required :id, :uuid
    optional :name, :string
    optional :age, :integer, min: 0
  end
end

And then use it in a controller or LiveView:

defmodule MyApp.SomeController do
  use MyApp, :controller
  
  alias MyAppWeb.MySchema

  def create(conn, params) do
    with {:ok, attrs} <- MySchema.validate(:create, params)) do
      ...
    else
      {:error, changeset} -> {:error, changeset}
    end
  end
end

You can have the schema inside the controller, it will work the same.

Example with LiveView

Version 0.2.0 adds conveniences for working with LiveViews, called changeset/2 and validate/2. They are used to build and validate a changeset that can be rendered in a LiveView (also works in HTML-controllers):

defmodule MyApp.SomeLiveView do
  use MyApp, :live_view

  alias MyAppWeb.MySchema

  def mount(params, _session, socket) do
    changeset = MySchema.changeset(:new, %{})
    socket = assign(socket, :changeset, changeset)

    {:ok, socket}
  end

  def handle_event("validate", %{"some" => params}, socket) do
    changeset = MySchema.changeset(:new, params)
    socket = assign(socket, :changeset, changeset)

    {:noreply, socket}
  end

  def handle_event("save", %{"some" => params}, socket) do
    with {:ok, attrs} <- MySchema.validate(:new, params)) do
      ...
    else
      {:error, changeset} -> {:noreply, assign(socket, :changeset, changeset)}
    end
  end
end

With these additions, it looks like Goal is running out of major functional improvements. The library’s behavior is very similar to Ruby’s DRY params and other mature parameter validation libraries. So I think Goal may reach v1.0.0 soon

I decided to add a function for outbound key recasing, because I need it in my apps and it seems intuitive that if you recase incoming parameters you would like to recase outbound parameters as well.

An example (with Phoenix 1.7 views):

config :goal,
  recase_keys: [to: :camel_case]

defmodule MyAppWeb.UserJSON do
  import Goal

  def show(%{user: user}) do
    %{data: %{first_name: user.first_name}}
    |> recase_keys()
  end

  def error(%{changeset: changeset}) do
    errors =
      changeset
      |> Goal.Changeset.traverse_errors(&translate_error/1)
      |> recase_keys()

    %{errors: errors}
  end
end

iex(1)> UserJSON.show(%{user: %{first_name: "Jane"}})
%{data: %{firstName: "Jane"}}
iex(2)> UserJSON.error(%Ecto.Changeset{errors: [first_name: {"can't be blank", [validation: :required]}]})
%{errors: %{firstName: ["can't be blank"]}}

The recase_keys/1 function should only be used when you are in control of the data that is being recased.

The updated docs are available on Hex: Goal 0.2.3