Previously, only a few specific changes supported using `arg/1` or `context/1`
in their options. Now, those templates can be used in any change options,
built-in or not.
These include:
- custom create/read/update/destroy actions
- changes
- preparations
- validations
- calculations
- manual relationships
See the respective DSL guides for more.
improvement: add more ergonomic manual action definitions.
The old method will likely be deprecated some time in the future (there is no rush really, they both work).
if a relationship was loaded previously we were just using that relationship value.
However, this has a chance to cause incorrect behavior in edge cases. One such
edge case is illustrated here: https://github.com/ash-project/ash/pull/434 We can return to the
more optimized behavior when lazy loading is improved via https://github.com/ash-project/ash/issues/438
prior to this, you had to say `map[:foo][:bar]`, but now you can also say
`get_path(map, [:foo, :bar])`. This makes certain things much clearer, i.e
`^arg(:foo)[:foo]`, which is problematic, would normally need to be written
as `(^arg(:foo))[:foo]` so that the pin only applied to the `arg/1` call.
This looks much nicer as `get_path(^arg(:foo), [:foo])`.
feat: add `Ash.Api.Info.depend_on_resources/1` to get the list of resources at compile time
A common desire is to have modules that validate things across Api modules, however `Ash.Api.Info.resources/1`
is not safe to use at compile time. `Ash.Api.Info.depend_on_resources/1` will set up the proper compile
time dependencies, making it safe to use at compile time
A compile env can be set to allow customizing the available type short names. This supports two things:
1. Adding custom type short names, like `attribute :price, :money` mapping to `MyApp.Type.Money`
2. Overriding the builtin type short names, like `attribute, :price, :string` mapping to a custom string type implementation (there is likely no reason to do this)
This helps with things like https://github.com/ash-project/ash_phoenix/issues/57
which involve rendering the relationship value after editing it. Retaining
the order allows direct reuse without any gymnastics
