Phoenix - Style Guide
26 Mar 2018naming
attrs vs. params
params
is what comes from controller - they might map to attrs
exactly or
not => use params
everywhere except for cases when it’s clear that you deal
with attributes - say, when you create a map of attributes by yourself or in
changeset functions inside schema modules.
NOTE: in Phoenix and Ecto docs they now use params
everywhere.
UPDATE
https://hexdocs.pm/phoenix/ecto.html#the-schema:
def changeset(%User{} = user, attrs) do
user
|> cast(attrs, [:name, :email, :bio, :number_of_pets])
|> validate_required([:name, :email, :bio, :number_of_pets])
end
https://hexdocs.pm/ecto/Ecto.Schema.html#many_to_many/3-join-schema-example:
def changeset(struct, params \\ %{}) do
struct
|> Ecto.Changeset.cast(params, [:user_id, :organization_id])
|> Ecto.Changeset.validate_required([:user_id, :organization_id])
# Maybe do some counter caching here!
end
https://hexdocs.pm/ecto/Ecto.Changeset.html:
def changeset(user, params \\ %{}) do
user
|> cast(params, [:name, :email, :age])
|> validate_required([:name, :email])
|> validate_format(:email, ~r/@/)
|> validate_inclusion(:age, 18..100)
|> unique_constraint(:email)
end
=> in most cases params
are used.
config
config/config.exs:
- configuration common for all environments
-
production configuration if it’s also meant to be used in test environment or when it’s important for application behaviour
production settings may affect application behaviour (say, rate limits) so these settings must be used in development as well to avoid situations when everything is okay in development but falls apart in production.
environment config (say, config/dev.exs):
- endpoint configuration (this is how config files are generated)
- very specific environment configuration (mostly development configuration)