WIP: Add Field::ActiveStorage

[goosys]

• issue Pull in administrate-field_active_storage #2899
• thanks https://github.com/Dreamersoul/administrate-field-active_storage
• ref https://railsguides.jp/active_storage_overview.html

WIP

index	form

Usage

apt install lib-vips

# config/application.rb
config.load_defaults "#{Rails::VERSION::MAJOR}.#{Rails::VERSION::MINOR}"
# Or,
# config/enviroments/development.rb
config.active_storage.variant_processor = :vips

bin/rails db:migrate

TODO

• Field
  • Base
  • PreviewRenderer
  • ItemsRenderer
  • Refactor
• Upload
  • has_one_attached
  • has_many_attached
• Direct Upload
  • Upload
  • Error handling
• Replace
  • has_one_attached
• Append
  • has_many_attached
• Remove
  • has_one_attached
  • has_many_attached
  • JS implementation
• Preview
  • Image
    • Original
    • Variant
  • Audio
    • Original
    • Previewable
  • Video
    • Original
    • Previewable
  • SVG
  • PDF
  • Previewable
  • File
  • Other file type(?)
• Delivery
  • rails_blob_url
  • Proxy (Rails.application.config.active_storage.resolve_model_to_route)
  • Proxy and CDN
  • Authenticated Controllers
• Style
• Test
• Document

[goosys]

@pablobm @nickcharlton

I'm thinking of using this Field with relatively complex behavior as a good example of RenderableObject. What do you think?

By introducing RenderableObject like this, we can separate the logic from the view layer, allowing application developers to tweak layouts or add styles without worrying about the underlying logic.

Or do you think it would be better not to use RenderableObject here? I’d love to hear your thoughts.

[nickcharlton]

Yeah, let's try RenderableObject and see how it feels. If it makes a complex change much nice, it's definitely worth it.

[goosys]

@nickcharlton @pablobm

I've been thinking about this again recently, and I'm starting to wonder whether it might be better to keep it as a separate plugin.

Rails' Active Storage is highly capable, and I found that even providing basic upload functionality required us to consider many different aspects. It has numerous configuration options, direct uploads require fairly complex frontend code, and testing uploads to cloud storage requires installing the relevant SDKs.

Given this complexity, I wonder whether developing and maintaining this independently as a plugin might be a better fit than integrating it into Administrate itself. I'd be interested to hear what others think.

[nickcharlton]

Yeah, that's a good point. My feelings on bringing in ActiveStorage support was mostly that it's a standard part of Rails and relevant to Administrate, and considering that we should out of the box support the relevant parts of Rails itself.

Is there something we could do to either cut down the scope we need to cover, or improve how we do testing?

The two things that come to mind are #3060 and #2830, but that just helps with testing and not limiting the complexity.

[goosys]

That's a fair point. I agree that Active Storage is a standard part of Rails and that Administrate should provide a well-supported way to use it.

However, I'm not sure that officially supporting it necessarily means that the implementation has to live in the main Administrate repository. For example, perhaps we could create an official plugin repository under the thoughtbot organization and include the plugin as a dependency of Administrate, so that it is available by default.

This could allow us to provide first-class support while keeping the Active Storage-specific implementation, dependencies, testing requirements, and release process separate from Administrate core.

Would that be an option worth considering?

[nickcharlton]

Having a new plugin repo is definitely an option worth considering. Being able to have tests for every scenario/configuration option is going to be so much easier to do on a repo of it's own.

I think (and forgive me for the possible scope creep here...) it'd be good to make sure we can build it from as perfect a fresh start as possible, with as good testing we can achieve from the beginning and then layer on the functionality. This might also mean fully revising the main Administrate docs on creating plugins, if we discover that they're a bit rubbish, for example.

There's a world here where we do this, get it stable and eventually pull it back into Administrate main anyway. I'd been pondering pulling in the nested has many field for example, which is stable and more annoying to maintain outside than it should be in.

[nickcharlton]

I think the next move here is going to most probably be on me. I'll need to create a new repo and bootstrap the start of the plugin (and this is where I'd probably look at revising the main plugin creation docs).

But I don't want to do that until I'm done with the Dev Containers work I'm currently looking at, and possibly the acceptance testing PR too because that will be directly helpful here.

[goosys]

Thank you! That order makes sense to me. Please take this on whenever you have the time, after the Dev Containers work and, if appropriate, the acceptance testing PR.

I have two additional thoughts.

First, regarding administrate-field-nested_has_many, I agree that bringing it into Administrate core may make sense because it depends on and interacts with many parts of Administrate. Another possibility might be to add only the core support for the concept that a field can be nested, while continuing to maintain the concrete NestedHasMany field as a separate plugin.

Second, since we may be revisiting the plugin creation documentation anyway, perhaps we could also provide a template repository for plugin authors. For example, we could create a repository containing a very simple field plugin, with the basic structure, test setup, CI, and other necessary pieces already in place, and publish it using GitHub's template repository feature. Plugin authors could then use that template as the starting point for new field plugins.

Do you think that would be useful?