Thread by @redrapids

Long @elixirlang / @elixirphoenix tweet... beware.

1- Layers

In the Workerbee book, we recommend layers for do-fun-things with big-loud-workerbees (boundary).

The data-functions-tests in the core are often wrapped in a boundary.

2- Mappings of services

In a typical @elixirphoenix app, the layers are:

Services separate a functional core (schema(s) and pure-ish module(s) in a context directory)

boundary is in a *context*.

Changesets get created in an ecto *schema* and applied in a *context*.

3- Mappings of layers in a live view

- The *render*, either in templates or a render function, is in the *core* layer

- Handlers are boundary concerns... all data must go through a boundary layer, often a context.

4- An exception to the above

Sometimes I have core features that I want to use within a LiveView, but I want to validate data that goes into them.

Schemaless changesets hexdocs.pm/ecto/Ecto.Chan… are ideal for this purpose.

Here's where the exception comes in.

5- I will put the schemaless changeset in my xxx_web/live/xxx_live directory as a *form_data.ex* module. The concerns are purely *LiveView boundary* concerns.

We did this in my LiveView class, and I'll likely do a form of it in my OTP class July 22-24.

Great technique.