Avo v3.0 feedback & ideas

[adrianthedev]

We'd love to see what you want & need from Avo 3.
You can find the milestone board on v3.0 here https://github.com/avo-hq/avo/milestone/1.

[mighani]

Besides table and grid views, what about a Kanban like view?

[adrianthedev]

We had a ticket like that at one point, but I can't seem to find it. Yeah, that could be something nice to have.

[rctneil]

Hi,

I'd love to see support for hierarchical content. Eg using differing methods of structuring this:

• nested_set
• parent_id's
• Or the method that the Ancestry gem uses ids that are "/" separated to indicate parent structure.

[adrianthedev]

Thanks for the feedback. AFAIK, Avo supports hierarchical content in the form of has_many. Not sure what the rest would look like. Can you share more about the nested_se, parent_id's or the other method? Something to describe how it works?

[rctneil]

Hi, This explains Nested set theory: https://en.wikipedia.org/wiki/Nested_set

Yes, Avo supports it in Many to Many, but sometimes, if using a third party gem to accomplish this sort of structure, it uses a different structure so being able to add support for different methods, (maybe along with dragging and dropping of records to reorder parents and children would be cool.

This is a gem that adds nested_set support: https://github.com/collectiveidea/awesome_nested_set. It stores the structure using lft and rgt fields.

Whereas The gem https://github.com/stefankroes/ancestry Ancestry, uses a field called ancestry where the structure is stored like //".

Other gems just use a parent_id column.

Being able to use Avo to manage this data using differing methods like described above would be super useful! Then it's not just catered to one method, but supports many!

[adrianthedev]

It seems you know a lot more about these things than I do. I'd love to merge a PR supporting this.

[iainbeeston]

Yeah I'm confused by this too, I have an avo app that uses awesome nested set and lets you recurse infinitely down into the hierarchy, and it works great! All I've done is use a field like this field :children, as: :has_many (and if you want the parent field :parent, as: :belongs_to) and it works great!

[khelal]

Any way of adding more "workflows" (doing action when objects changes) & "collaboration" (chat, tags, tasks,...) features to help streamline a lot of the grunt work?

[adrianthedev]

Hey @khelal. Thanks for writing!

1. Workflows; Can you talk more about those? Can you give me an example or two that you needed in the past or see that Avo requires?
2. Collaboration; Is this something that you'd need on any app? Chat between the users of the app? What about tags? How would they work? Would they be global?

I'd love to have a chat with you to tell me more about these things?

[khelal]

Well the idea is to be able to have discussions / tasks / workflows internally based on specific things.

So if we go back to your "Room Booking" demo, imagine having a supervisor that would need to approve any changes to the rooms or buildings, and being able to have internal discussions between the user and the supervisor on these objects. That changes Avo from being an "admin" platform to being a proper business tool that can implement some logic.

I realize all this can be done at the App level too, but if there's a way to do it in the Engine side of things, it'll make things more clean imho.

[adrianthedev]

Got it! It makes sense to have the collaboration tools available. I'll add that to the roadmap.

Regarding the approval process, yeah, I think we're in the stage of having those at the app level.
It would be a good idea to have a plugin that does that.

[adrianthedev]

BTW, Thanks for sharing! It's the way to push this forward!

[khelal]

My pleasure! Since we're at it, any easy way to integrate with something like LeafLet or MapBox to display objects with lat/long coordinates on a map? How about dynamic filters and saved scopes?

[adrianthedev]

Regarding LeafLet or MapBox: Yes! Depending on what type of integration you need, you can achieve that using custom fields or resource tools to manually embed it on the resource page.

Regarding dynamic filters and scopes, they are on the Avo v3.0 roadmap.

[adrianthedev]

hey @khelal. we have a couple of updates to this.

easy way to integrate with something like LeafLet or MapBox to display objects with lat/long coordinates on a map

This has been added to Avo.

How about dynamic filters
Done! added

saved scopes?

We have file-backed scopes. We'll add db-backed scopes soon.

[iainbeeston]

I'd love a more powerful file field, that allows you to pick images or files from a third party API or a gallery of active storage attachments (probably using a scope)

[adrianthedev]

I guess that feature is quite specific. APIs can be very wild. Maybe if we narrow it down to a specification, we could make something, if not, there's always the option to add a custom field that does that.

[adrianthedev]

@iainbeeston could you tell us about your file API scenario? What were the necessities and what did you have to do to make it work? We might bring that support into Avo if it makes sense.

[Paul-Bob]

@iainbeeston, we'd love to get more context about your scenario.

I've created an issue here: #3161.

Let's continue the discussion there.

[iainbeeston]

Something that would be good in a version 3 is a rethink of how associations and the via resource and via relation params work. I call this nested resources. Right now it’s very difficult to customise redirects after saving nested resources, it’s also difficult to handle breadcrumbs for them correctly. There’s a lot of code in base controller that references these “via” parameters that controls the logic of the controllers. I wish it was refactored out into a single place that was easy to customise, or could be controlled in a resource class

[adrianthedev]

Thanks Iain! I'd love to bring these in the next version. Could you help with a few more details please?

it’s very difficult to customise redirects after saving nested resources

What would you like to achieve with those redirects? Can you share a scenario where you needed that?

it’s also difficult to handle breadcrumbs for them correctly.

Can you share a scenario where the breadcrumbs are not working properly?

There’s a lot of code in base controller that references these “via” parameters that controls the logic of the controllers.

Yes. The via request params enable us to send the current "state" to the server. Not sure how we could send that without those params. I'm open to suggestions to improve that.

I wish it was refactored out into a single place that was easy to customise, or could be controlled in a resource class

Again, an example scenario would help me understand the requirements better.

[rickychilcott]

Three DX requests:

1. Do a thorough review of all fields and make all of them "callable". I suspect that 80% are, but there are some inconsistencies, and a thorough review might just allow it to be knocked out in one fell swoop

2. It'd be nice if there was a module that could provide a set of capybara test helpers (for rspec and minitest) that can be included in system specs. For more complex admin interactions, I write tests and the markup changes on pretty much every release. I can share some of my own helpers, if they are helpful, but it'd be nice if they were used by Avo internally so they'd be updated with each release.

3. Ensure all field types are useable in actions. I think at some point, not all were available, but we should ensure they all can be used.

Keep up the great work folks!

[adrianthedev]

Thanks for writing Ricky.

1. This is one of the things we worked on first. Creating a smarter ExecutionContext object that can execute callables much easier and in a more uniform way, and yes, we're going to make a lot more options and attributes callable.

2. Hmm. Got it. I understand the frustration of the markup being changed. We'll think of a way to have that more stable or maybe better attributes (maybe data attributes) that don't change as often as classes do.
   We'd love to have a look at your helpers and see how we can integrate them into Avo natively. Can you make a gist (or any other way that's more comfortable for you) to share them with us?

3. Yeah. We have improved the fields and actions compatibility levels, but we haven't checked all of them. Maybe we should do more thorough testing.

This is the kind of feedback that helps us make Avo better 🙏

[iainbeeston]

I’d also like number 2 - I have some test helpers for avo similar to capybara’s form helpers, to fill in trix fields and things, but an official solution would be much better

[rickychilcott]

Here are some of the helpers I've created: https://gist.github.com/rickychilcott/95d92564179f2d96dac9b5bfa4c8d1ab

Feel free to use.

[adrianthedev]

Thank you Ricky! It definitely helps to see real-world code.

[rctneil]

I'd love to suggest dynamic fields. We have some edit fields that only show up depending on the value of another field. If the field was changed, we currently have to save the changes then go back into edit mode in order to see the new field that is conditional of the first one.

A few options to show or hide fields based on other field values would be amazing and add some dynamism to the editing experience.

[rickychilcott]

I suspect you mean this without writing any javascript. This, of course, could get complex if you tried to do it all client side.

But maybe there is a pattern in hotwire-land that could allow this sort of thing server-side and not client-side. 👀

[rctneil]

Yes, ideally, I just feel it would allow the editing experience to be custom to what a user is inputting when they come across conditional fields etc

[adrianthedev]

Got it! Some kind of dependable fields. I think we could do that using some Hotwire magic 😉.

It's on the roadmap for v3 👍 Thanks!

[iainbeeston]

It'd be great if avo had support for delegated type fields. I think this could work like a belongs to association?

[adrianthedev]

I think that's supported. Is there anything missing or something we can improve?

[nhorton]

It would help a ton if the search on the documentation page could be updated so that search from 3.0 pages showed search results for 3.0 instead of 2.0.

[adrianthedev]

I agree! We are using Vitepress for our docs.
I don't have a good solution for that right now. We're open to ideas.
We will switch all search from 2.0 to 3.0 after we launch the new version.