Awesome post! I’ll specifically address the Ash querying parts.

It should be pretty straightforward to select attributes when running Ash queries. For example:

Ash.Query.select(query, [:foo, :bar, :baz])

If you are using a code interface function, you can provide a query option:

DomainOrResource.code_interface_function(..., query: Ash.Query.select(Resource, [:foo, :bar, :baz]))

Or you could add a select in the action:

read :home_page do
  prepare build(select: [:foo, :bar, :baz])
end

I could add a select option to code interface functions if that would make it more ergonomic to select individual fields, i.e DomainOrResource.code_interface_function(..., select: [:foo, :bar, :baz])

Interesting write-up, @lardcanoe

The reconnecting flash of death

This is a bit of a problem at my current company though it never seems to hang. We solved it by putting a delay. There is discussion around this here and I believe this will be available as an option in the next release of LV.

Having said, that, this is something I have always wondered about and never get too much feedback on it. Many people say it’s never a problem, others say it is sometimes, others say often. I do wish there was more constructive discussion around this. Maybe there is and I’ve missed it. I do spend an obscene amount of time reading this forum but of course said discussion could exist on other channels.

Another thing I will say is that I was running a project app on Fly and saw this constantly whereas my one other friend using the app said they rarely saw it. I’m currently running a client app on AWS and it’s not been much of a problem at all. I do find it odd that it continually seems to be a problem on Fly when it’s a Phoenix-heavy service. Maybe it has to do with the plan level? I have noooooo idea.

And of course I must point out to address the other part of your concern: you can re-style it to not be so scary!

Temporary_assigns

This is another area I think about a lot, though I think the default is good as it is. It is our state after all so I think the expectation that the default is to store is a good one. I haven’t worked on a LiveView site with tons of traffic before but I do wonder how much of a memory burden storing all that state server-side really is. Like, so long as you’re being relatively conservative, I figure it can’t be worse than all the temporal memory used by stacks that re-build the entire world on every request. Of course this is just a hypothesis and is something I’d love to see more discussion around (mostly hearing peoples’ experiences).

I do this sometimes and I don’t (yet) use Ash. I either need everything or use multiple schemas point at the same table to grab smaller slices of it for different scenarios. But this doesn’t really answer your question about Ash.

hexdocs.pm search

I agree here, though I’m going to throw a lil’ bit of your 'tude back at ya and say “feel free to get the ball rolling yourself to fix it” At least comment on the ongoing issue in the ex_doc repo to improve search. José and co are incredibly welcoming.

In any event, thanks for the post and I hope some good discussion comes out this!

Ah, that is the way to select while using the code interface. It isn’t too bad. I’ll switch over to that and see how it goes for the next few weeks.

Being able to pass in select: is the ideal path, but don’t change anything since the query approach works.

But what has been the best practice approach for all the projects that you use Ash for? The ones that pay the bills. Do you just select everything? Do you mostly select the attributes that you need, and if so, what approach do you use?

I’ve been torn the past few months because there are some things I’ve learned you just do, but I’ve been kicking the can down the road since they weren’t so obvious how to do, or were overly verbose/tedious. Changing code that is doing select * to only selecting attributes is really hard to change, and very error prone. I should not have let myself go this long doing it.

Honestly it’s hard to say. It depends entirely on the real characteristics of the app I’m building. Like is this an admin tool for some low number of users to munge some data? Don’t bother with selecting. Is this a consumer facing money-making app that has to sail and feel good to use? Then yeah, applying a select always is good practice. You could theoretically even enforce it with something like this:

preparations do
  prepare fn query, _ -> 
    Ash.Query.before_action(query, fn query -> 
      if query.select, do: query, else: Ash.Query.select(query, [])
    end)
  end
end

That makes selecting a requirement.

What I do see is LiveView clients reconnect and they are on an older version of the CSS bundle, so might be missing some classes.

There’s static_changed?/1 to address exactly that need. By default the CSS and JS bundles are tracked, but the page is not auto-reloaded.

Made me chuckle…