Skip to content
Draft
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions installer/test/phx_new_test.exs
Original file line number Diff line number Diff line change
Expand Up @@ -555,6 +555,12 @@ defmodule Mix.Tasks.Phx.NewTest do
assert file =~ "inputs: [\"*.{heex,ex,exs}\", \"{config,lib,test}/**/*.{heex,ex,exs}\"]"
refute file =~ "subdirectories:"
end)

assert_file("phx_blog/AGENTS.md", fn file ->
refute file =~ "Ecto"
refute file =~ "changeset"
refute file =~ "Ecto.Schema"
end)
end)
end

Expand Down
23 changes: 23 additions & 0 deletions usage-rules/ecto.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,3 +7,26 @@
- You **must** use `Ecto.Changeset.get_field(changeset, :field)` to access changeset fields
- Fields which are set programatically, such as `user_id`, must not be listed in `cast` calls or similar for security purposes. Instead they must be explicitly set when creating the struct
- **Always** invoke `mix ecto.gen.migration migration_name_using_underscores` when generating migration files, so the correct timestamp and conventions are applied

### Creating LiveView forms from changesets
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only moves the problem around. Now, you'd get LiveView content when you use --no-live. For the AGENTS.md, we could solve this by using .md.eex files and then checking <%= if live do %> etc., but since these files are also valid usage_rules, so we can't use eex :(

Maybe we need to split this even further, into an ecto-liveview.md and concat that conditionally? Although this refers to LiveView, the content is also valid for Phoenix forms without LiveView.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch!


When using changesets with LiveView, the underlying data, form params, and errors are retrieved from it. The `:as` option is automatically computed too. E.g. if you have a user schema:

defmodule MyApp.Users.User do
use Ecto.Schema
...
end

And then you create a changeset that you pass to `to_form`:

%MyApp.Users.User{}
|> Ecto.Changeset.change()
|> to_form()

Once the form is submitted, the params will be available under `%{"user" => user_params}`.

In the template, the form assign can be passed to the `<.form>` function component:

<.form for={@form} id="todo-form" phx-change="validate" phx-submit="save">
<.input field={@form[:field]} type="text" />
</.form>
2 changes: 1 addition & 1 deletion usage-rules/elixir.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@
end

- **Never** nest multiple modules in the same file as it can cause cyclic dependencies and compilation errors
- **Never** use map access syntax (`changeset[:field]`) on structs as they do not implement the Access behaviour by default. For regular structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist, `Ecto.Changeset.get_field/2` for changesets
- **Never** use map access syntax on structs as they do not implement the Access behaviour by default. For structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Never** use map access syntax on structs as they do not implement the Access behaviour by default. For structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist
- **Never** use map access syntax on structs (`my_struct[:field]`) as they do not implement the Access behaviour by default. For structs, you **must** access the fields directly, such as `my_struct.field` or use higher level APIs that are available on the struct if they exist

- Elixir's standard library has everything necessary for date and time manipulation. Familiarize yourself with the common `Time`, `Date`, `DateTime`, and `Calendar` interfaces by accessing their documentation as necessary. **Never** install additional dependencies unless asked or for date/time parsing (which you can use the `date_time_parser` package)
- Don't use `String.to_atom/1` on user input (memory leak risk)
- Predicate function names should not start with `is_` and should end in a question mark. Names like `is_thing` should be reserved for guards
Expand Down
30 changes: 3 additions & 27 deletions usage-rules/liveview.md
Original file line number Diff line number Diff line change
Expand Up @@ -186,29 +186,6 @@ You can also specify a name to nest the params:
{:noreply, assign(socket, form: to_form(user_params, as: :user))}
end

#### Creating a form from changesets

When using changesets, the underlying data, form params, and errors are retrieved from it. The `:as` option is automatically computed too. E.g. if you have a user schema:

defmodule MyApp.Users.User do
use Ecto.Schema
...
end

And then you create a changeset that you pass to `to_form`:

%MyApp.Users.User{}
|> Ecto.Changeset.change()
|> to_form()

Once the form is submitted, the params will be available under `%{"user" => user_params}`.

In the template, the form form assign can be passed to the `<.form>` function component:

<.form for={@form} id="todo-form" phx-change="validate" phx-submit="save">
<.input field={@form[:field]} type="text" />
</.form>

Always give the form an explicit, unique DOM ID, like `id="todo-form"`.

#### Avoiding form errors
Expand All @@ -223,9 +200,8 @@ Always give the form an explicit, unique DOM ID, like `id="todo-form"`.
And **never** do this:

<%!-- NEVER do this (invalid) --%>
<.form for={@changeset} id="my-form">
<.input field={@changeset[:field]} type="text" />
<.form for={@data} id="my-form">
<.input field={@data[:field]} type="text" />
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this change is good, as nobody would write that, and it probably doesn't really get the point across to the LLM.

</.form>

- You are FORBIDDEN from accessing the changeset in the template as it will cause errors
- **Never** use `<.form let={f} ...>` in the template, instead **always use `<.form for={@form} ...>`**, then drive all form references from the form assign as in `@form[:field]`. The UI should **always** be driven by a `to_form/2` assigned in the LiveView module that is derived from a changeset
- **Never** use `<.form let={f} ...>` in the template, instead **always use `<.form for={@form} ...>`**, then drive all form references from the form assign as in `@form[:field]`. The UI should **always** be driven by a `to_form/1` or `to_form/2` assigned in the LiveView module