AMA with: Zach Daniel and Rebecca Le (codebar Winter Lit Fest)

Community In The Spotlight
, , ,
23

Nice. I guess I deserve bonus points for being a good memory bot.

Looking forward to that addition!

2 Likes
24

Hmm this doesn’t sound good. Is it the same situation with Phoenix and why it doesn’t have destroyers?

What would it take exactly for this to become possible? I’m a noob here so pardon the “Why? Why? Why?” questions. Is this a limitation of Elixir as a language or Phoenix as a framework?

If you can give me a simple analogy that would be best. I don’t want you to overthink it or dig too deep and end up killing the vibe :slight_smile:

1 Like
25

It definitely isn’t a limitation of Phoenix/Elixir etc. It’s just the way that code works in terms of additions/removal. Adding new code is easy because it is dependency-free. Removing code is the Wild West because anything anywhere can depend on it.

When you have a resource like MyApp.Post, you might call actions on that resource in any number of different files. The resource definition is self-contained, but references to it are not. For example, let’s say you have a MyApp.Blog.Post resource.

defmodule MyApp.Blog.Post do
  use Ash.Resource, data_layer: AshPostgres.DataLayer

  actions do
    defaults [:read]
  
    create :create do
      accept [:title, :text, :author_id]
    end
  end

  attributes do
    uuid_primary_key :id

    attribute :title, :string do
      allow_nil? false
    end

    attribute :text, :string do
      allow_nil? false
    end
  end

  relationships do
    belongs_to. ;author, MyApp.Blog.Author
  end
end

and then you have some code somewhere else that you call when you want to generate some demo data. Maybe for demoing to customers, or for testing etc.

defmodule MyApp.Blog.Demo do
  def create_demo_data() do
     author = MyApp.Blog.create_author!()

     [
      %{title: "Demo Title", text:  "demo text", author_id: author.id},
      %{title: "Demo Title2", text:  "demo text2", author_id: author.id}
     ] 
     |> MyApp.Blog.create_post!()
  end
end

We could call mix ash.remove.resource MyApp.Blog.Post which could remove the resource, and its reference from its domain, but what should happen to MyApp.Blog.Demo? It’s just doing something invalid now. We could scan your codebase for references to the resource, but how would we know what to do with that code once we found it?

It is likely that the author resource has a has_many :posts, Post relationship, should we delete that? If we do, what else will it break? Maybe they have a count :count_of_posts, [:posts] aggregate. We’ve gotta find all of that stuff and remove it? What about if there is another resource called MyApp.Blog.Comment that has a required belongs_to relationship to MyApp.Blog.Post? Do we delete that whole resource? etc. etc. etc.

Its turtles all the way down :laughing:

My tone above wasn’t meant to sound frustrated, it’s an interesting question and one I’ve enjoyed answering. I was only trying to illustrate that attempting to automatically remove some piece of code and leave the user with a still valid application is a huge can of worms (and likely just an impossibility in general).

The feature could be added that just removes the resource and the domain reference, and then just compiling the app would probably fail and you’d have to go figure out why, but the value in that is pretty low given that you can get there yourself by deleting one line of code in the domain and deleting the resource file :smiley:

3 Likes
26

No offence taken. So no worries :slight_smile:

This response is the winner for me. Thanks for the explanation and the laughs haha :smiley:

3 Likes
27

Hi! is it [possible] to create like maintenance page, or something like a read-only? like a temporary state.

1 Like
28

My initial thought was ‘that wouldn’t be Ash’s responsibility’, and if you wanted to put up a maintenance page, it probably wouldn’t be - that would be the responsibility of your web framework.

A read-only view of your app though - that sounds doable, with policies. If you had an ENV var setting MAINTENANCE=true or something similar, you could have a policy in each of your resources like:

policy action_type([:create, :update, :destroy]) do 
  authorize_unless <the ENV var is true>
end

Enabling/disabling the maintenance mode would involve setting/unsetting the env var, and restarting the app. I haven’t implemented it, but it sounds possible to me!

2 Likes
29

Hello everyone!

I’m your friendly Devtalk bot :nerd_face:

Thank you to all of you who participated in our Spotlight AMA!

This is now closed and all of those who commented above have been entered into the draw - meaning we’re now ready to pick a winner!

The process will be initiated when somebody clicks the special link below:

:arrow_right: :arrow_right: :arrow_right: Devtalk - Dev forum at Devtalk - the forum for developers! :arrow_left: :arrow_left: :arrow_left:

Don’t be shy, we need one of you to help make the magic happen! :sparkles:

2 Likes
30

Thank you for initiating the draw process


Entering the following members into the draw


:arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down:

1 Like
31

And the winner is


Drum roll


1 Like
32

Congratulations @jaeyson you are the chosen one!! We’ll be in touch about your prize via PM soon :smiley:

Thank you everyone who entered, and of course @zachdaniel and @sevenseacat for taking part in our Spotlight - thank you! :blue_heart:

3 Likes
33

Hi Rebecca.

I added live_select with the sample code : city_select with fixed cities to my app and it works wonderfully.
Now I have to adapt it: query my artist-resource,

Thanks again for pointing out this component. :grinning:

I found a small issue: The example code still uses form_for instead of <.form :let={f}

Best wishes from Heiko

1 Like