Just thought we’d mention that Rebecca Le will be presenting at the upcoming Elixir Sydney online meetup tomorrow about writing the book and there’s a special offer to attendees.
melissaloh
sevenseacat
Author of Ash Framework
sodapopcan
Sorry to hear you’re going through heck, @stevensonmt, hoping things ease up soon.
I finally bought this book today and went through chapter 1. I had already started developing an app in Ash and was already familiar with most of the concepts but it really helped solidify them as it’s explained a little better than in the docs. Or at least, in a better linear way than the docs. For instance, it really hit home how the :get_by option in code interfaces works. From the docs I understood that :read always works on collections. Adding the :get_by option seemed almost arbitrary and I was struggling to figure out the reasoning as to why this API was chosen. It was the book that described it as a filter which makes a ton of sense. I’m not sure the docs actually describe it this way but I’ll open a PR to add it if I can’t find it.
Another thing of note is that I love love love the AshPhoenix.Form API (well, except where you do to_form(form)… that is a little weird 
). It’s of course following “describe your domain, derive the rest” but I specifically like how it even calls effectful functions for us with AshPhoenix.Form.submit.
One thing I don’t love is AshPhoenix.Extension, ie, form_to_. What I would prefer—and I feel like this was probably considered and abandon—is if AshPhoenix.Form.for_create and friends could also take a Domain + function combo as opposed to just Resource + action. I feel like this would make it more consistent with how forms are otherwise used and that for_create(Tunez.Music, :create_artist) is less confusing than a form_to_ prefixed function seemingly coming out of nowhere. But form_to_ isn’t terrible as it’s something you use so often that it would be hard to forget what it means.
2
FlyingNoodle
Domains also generate can_<insert_action_name_here>? functions on the domain, so it’s not that strange.
0
sodapopcan
I didn’t say it was strange, just not as clear as the resource version. I feel roughly the same about the can_ ones. But again, it’s by no means terrible and easy to get used to.
0
zachdaniel
Creator of Ash
Ultimately what we’ve found in practice with really large applications is that it can become really hard to track down action invocations when they use the format SomeMod.some_fun(Resource, :action). Refactorability is pretty high on the priority list, so form_to_ was added to make sure that you could always track down where something was being used, including in forms. If you were to remove or rename the action and code interface, you’d get a compile warning for using an unknown function, whereas you’d have to hunt down atoms using AshPhoenix.Form.for_create(...). Doesn’t change the fact that it can feel kind of strange to do it 
but that is the original rationale for the addition.
0
sodapopcan
Oh ya ok I see, that’s a very good reason, then! Again, I don’t really mind it… I dunno, I guess @FlyingNoodle was right, I am saying I found it strange 
It’s definitely strange having the domain layer send you a form struct but it all makes sense with how Ash is designed and just takes some (slight) getting used to.
1
ghannam80
Hi @sevenseacat ,
Thanks for the book and finally getting to connecting the dots together when it comes to Ash framework.
I had a question with regards to API , if we would like to get a response in a format like :
{
“name”: “Testing Tunez”,
“artist”: “John”,
“born”: 1980,
“albums_count”: 5
}
is this possible with Ash JSON?
0
zachdaniel
Creator of Ash
AshJsonApi’s primary goal is to create a JSON:API compatible API. The spec is documented here: https://jsonapi.org
When you meet that spec, you get a lot of benefits 
However, if you must make something that doesn’t match that spec, you can use generic actions:
action :your_action, :struct do
# it returns a struct which is an record of this resource
constraints instance_of: __MODULE__
argument :id, :uuid, allow_nil?: false
run fn input, _ ->
Ash.get(__MODULE__, input.arguments.id)
end
end
Then you could put that in your API with route/3:
route :get, "custom/route/:id", :your_action
2
ghannam80
Thanks , it worked without any issue.
As for the standard , I am not sure what is the reason but in our domain “payments” most API written are returning such non standard output.
0