Hey all, have been looking through the source code...
# avo-2
f
Hey all, have been looking through the source code of avo, and can't figure out at what point is a resource instantiated?
Copy code
app/controllers/avo/application_controller.rb:120

    def set_resource
      raise ActionController::RoutingError.new "No route matches" if resource.nil?

      @resource = resource.hydrate(params: params)
    end
I think this should be the point, but if we look at how
def resource
is defined - it should return a
class
while
#hydrate
is an instance method on
BaseResource
l
hey Martin
you're on to something, but not quite there
let me send you a link
f
Awesome! Thank you!
when we boot the app we register and initialize all the resources here πŸ‘†
then, using methods from
fetches_things.rb
we get the instances and hydrate them at a later time when we have everything https://github.com/avo-hq/avo/blob/main/lib/avo/concerns/fetches_things.rb#L33
it's not the best approach but it's how we got started with that API
we're improving things a bit with Avo 3
f
Yes! That makes sense now. I was confused by
and the comment here of returning a
UserResource
- its'a actually an instance of user resource?
l
that's correctπŸ‘†
we also instantiate them once more on boot time but earlier when the routes are set https://github.com/avo-hq/avo/blob/main/lib/avo/dynamic_router.rb#L20
we removed this in Avo 3
f
great! I see
Yes, and to > we removed this in Avo 3 > it's not the best approach but it's how we got started with that API I was thinking abotu this "hydrate" not being the best coding pattern, and was about to ask if you have plans to change it for V3
l
how should we signal in that comment that this is an instance?
f
but you're already ahead of the curve I see : )
l
we are still hydrating things a bit πŸ˜…
but less πŸ˜›
f
> how should we signal in that comment that this is an instance? Good question, not sure, don't think there's a standard, maybe either
get_resource_by_name('User') => instance of UserResource
or
get_resource_by_name('User') => #UserResource
l
hmmm. I think
#
is used for static methods
I was thinking
<UserResource>
WDYT?
f
Not really obvious to me, maybe others would have better ideas. I'd probably write out
instance of <UserResource>
l
yup. makes sense. thanks!
f
Okay, and let me ask you about the hydate -
l
sure
FYI: I'll go into a meeting in 10 minutes
but go for it
f
np
was justa short question on what you plan to replace it with - instantiation of every field
as currently - don't you get into thread safe issues?
l
I think we are πŸ™‚
f
πŸ™‚ good, okay that confirmed my understanding! : )
l
I mean... I haven't seen any Avo apps that get that amount of traffic that they are actually getting into thread safe issue
f
Was more wondering from a coding perspective if my understanding is right... yeah
l
we are using the
Current
model in Avo 3 more for holding
params
and other things
f
I see
l
that's thread-safe
but still... we could improve there
f
and then, you probably don't hydate, but just would instantiate new fields for every record?
l
it's good we're having this convo
f
in a more functional way?
l
yes, but probably not a silve bullet solution πŸ™‚
you see, the resource is not only used when displaying the record
we use it a lot of times before
when we generate the routes, the metadata, and more
and that's why sometimes it's better to have it before hand
f
Oh, I see, that's the reason! I think there's probably an abstraction missing - something about using the resource on a "Record" level vs using the resource on class level .. okay was able to understand the problem better. Thank you!
Thanks again for all answers! Much helpful!
l
yes. probably an internal abstration, yeah
yeah. definitely. I love speaking about these things
always fleshes out new and old things we cn improve