Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will v1.0.0 provide built-in support for Active Storage and Action Text? #2517

Open
seanpdoyle opened this issue Feb 14, 2024 · 1 comment
Open

Comments

@seanpdoyle
Copy link
Contributor

  • What would you like to be able to do? Can you provide some examples?

Active Storage and Action Text are built-in frameworks that are several years old at this point. They've proven to be stable, and as time goes on, are more prevalent. Administrate has an opportunity to support them as part of a major version bump from 0.20.0 to 1.0.0.

  • How could we go about implementing that?

#2411 is an open pull request that aims to incorporate Trix and Action Text-backed field support. Do the asset changes merged in #2397 make that prospect require fewer changes?

Similarly, https://github.com/Dreamersoul/administrate-field-active_storage/ is a third-party integration that adds support for Active Storage. Is there interest from that projects maintainers to upstream that support? Do the asset changes merged in #2397 simplify the JS-side of the equation? Is there a portion of what that gem provides that could be upstreamed?

  • Can you think of other approaches to the problem?

Alternatively, built-in support could be added directly, without influence from the https://github.com/Dreamersoul/administrate-field-active_storage/ codebase. Since it's likely that the project's maintainers have some valuable earned wisdom from its use in various production environments, that feels risky.

@nickcharlton
Copy link
Member

I think that's a good goal to set, my feeling is that "standard" Rails stuff should be supported. I expect #2411 to go in before the final v1.0.0 release, and this would indeed set that expectation.

My preference would be to try and bring in the existing work — it'll be much less risky. I think the next thing to do here would be to open an issue on plugin's repo and go from there. Is that something you'd be able to do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants