Field type that can use a resource that is not persisted

[segiddins]

I think trying to summarize this in a title probably made it even more confusing 😅

I'm creating an active record subclass that uses attribute to serialize/deserialize a JSON field to another class, which happens to be an ActiveModel subclass.

I've been poking around, and it seems doable to create a subclass of the HasOneField where the show component directly embeds the ResourceComponent for the attribute, but it doesn't look 100% natural, and I also haven't gotten around to testing updates yet. There was also some hackery needed to work around the assumption that every resource's model has an id field.

This is what I've got for now, but I was wondering if you have anything on the roadmap to make embedding these sort of resource fields (that don't map to persisted records) any easier?

[adrianthedev]

@segiddins can you share some code for this? A reference to a PR is fine if you have it (snippet will do too).

[segiddins]

rubygems/rubygems.org#3716 see the ArrayOfField and NestedField types that I added

[adrianthedev]

Wow... You took the Avo DSL to a whole new level 😛
It's very interesting to see how you evolved it. I rarely see folks go so deep, though I hoped they would. I want people to be able to "hack around" Avo and not rely only on the basic features. Good job for that!

Right now, the "embedded fields" (has_one, has_many) rely heavily on the _reflections property on the record, which comes from the AR associations. Avo needs some information from those properties to be able to read & update the data correctly.
We definitely want to explore removing that dependency and allow for more "general data associations" like serialized data and non-Active-Record resources, but that will happen later this year after we launch Avo 3.

More plainly, I'd be open to a PR if we had one, and the functionality would be "general enough", so yes, let's keep this conversation open.

[segiddins]

I think the approach I ended up taking is probably a pretty "safe" one. It does not use any reflection, and only assumes that the "nested" object looks like an active model. Avo should not need to know anything further than the nested field types given by the user (either the array member field or the fields inside the nested field), because active model attributes already handle typecasting.

I guess to be blunt, would you be interested in me contributing those fields as they are in that PR? I would of course be happy to add additional test coverage for them, but they seem to be working for both show/edit views, and handle pointing out validation errors in the nested model & persist when saving on new/edit fails. One thing I could make a bit prettier would be to allow disabling the field headers for the array member field, which would allow the arrays to flow more naturally.

In addition, we probably want some way to inject errors into the individual edit components so they appear inline, but that seems pretty easy to do.