avo-hq / avo

Build Ruby on Rails apps 10x faster
https://avohq.io
Other
1.49k stars 233 forks source link

Attach Fields - Also for Create #3242

Open rctneil opened 1 week ago

rctneil commented 1 week ago

In regards to the attach_fields option.

If the Record you wish to attach does not actually exist and you have to create it by clicking the "Create xxx" button, the attach_fields should be available somehow in this workflow too.

This would ensure that both the Attach and Create options work the same way and can end with a consistent result.

Workaround:

  1. Create new item.
  2. Detach item from record.
  3. Re-attach and complete the attach fields in the popup.
Paul-Bob commented 1 week ago

Hello @rctneil.

I get the use-case and it can be custom-implemented already.

1 - Define the fields from atach_fields on that resource you are creating, you can even make a visible block considering the presence of a parent resource/record and make them visible only when created from a specific association. 2 - Using create_success_action and params to fill the join record on the avo controller.

def create_success_action
  @record.join_record.update!(some_attribute: params[...][:some_attribute])

  super
end

How do you think this feature should be integrated into Avo? We should consider that not all use cases may want this behavior, maybe some people want it only on attach.

rctneil commented 1 week ago

Ok, I'll try custom-implementing this.

I do still see this as a feature that Avo should offer. To accomodate more users, may an opt in approach would be useful?

Eg, keep the custom functionality as it is but provide an on_creation: true option on attach_fields?

Maybe it's not suitable for integration, but thought I would suggest it anyway as more ideas are always good i guess.

Paul-Bob commented 1 week ago

Maybe a new option: create_fields

def the_fields
  -> {
    field ...
  }
end

def fields
  field ...,
    attach_fields: the_fields,
    create_fields: the_fields,
end

Whatever the DSL is we would render them in a static position on the page probably at the end of the page, then if you want the fields on a panel or in a sidebar, or even in a tab you will still fall back to a custom implementation. IMHO if the custom implementation is straightforward and not that time-consuming is worth documenting a recipe instead of implementing a native feature that limits the posibilities.

but thought I would suggest it anyway as more ideas are always good i guess.

For sure! New ideas and feedback are always welcomed, thank you for that!

Ok, I'll try custom-implementing this.

Let me know how it goes, and if you find any obstacles, maybe we could create a recipe and document it because the workaround isn't pleasant.

rctneil commented 1 week ago

Ok, Yes, I'll try to test it out this weekend and will report back.

The create_fields idea is actually much nicer, as it's clear where those fields will be used. Yes, bottom of the page sounds fine to me as a default.