I’ve been thinking a lot the last ~18 hours since taking a serious try and stab at Hanami, coming from using rails since 2013 and I realized that I personally will need some of these batteries included things to feel comfortable and productive using Hanami. I think there’s likely a cohort of Rails users who would try Hanami if there were options that felt like they weren’t leaving them behind to build themselves (yes even with Shrine existing for file uploads).
Now I’m completely happy to work towards this myself with others too (if they want!) at building some of these things. Almost every app I’ve made has some variation of file storage + rich text editing. As they say, if you want to see it you may have to build the future you want.
In Rails you can reach for as mentioned ActiveStorage and ActionText to handle storing the files / text content. I’ve been working today to explore a slice for Storage of files / blobs / whatnot, not made a lot of progress yet but I’m learning a ton in this endeavor. I’ve built a rich text solution using a TipTap based text editor for Rails (richer-text gem), that could be adapted for Hanami one day, or even a custom built one for the needs of the Hanami community too could be done .
I’ve used Shrine in Rails apps before and it’s a good solution, but I want something hands-off like ActiveStorage is once you set it up. I realize for many, Shrine probably meets that criteria for them, but it’s still a lot to do judging by some blogs I’ve seen on Hanami + Shrine.
To me the magic is like;
Okay so we’ll (the gem) handle the uploading + processing the file uploaded + storage with adapters for the common services (Disk / S3 / whatnot).
You handle adding a config line to setup the association in your relations (somehow, idk how yet!) + form field where you want it and then viola you have your file uploads working
You configure if you need S3/R2/etc whatever storage solution in your .env file instead of the default disk storage.
Then you get provided ways to access that uploaded blob on the relation and grab the url / cdn url or whatever you need.
In my mind the perfect install process is like:
Add the gem
Setup your .env for desired storage adapter and required credentials if any (disk, s3, etc)
Run a command to get the migrations dumped into your db migrations & run db migrate.
Add a line to your relations to enable the associations
Add your form field to your forms + perhaps permit/require it in the create params block in the action for that form?
Call book[:cover_image].url=> signed s3 url for accessing the file that expires in a configurable timespan.
Not sure if this sounds too Railsy but it’s what I’m exploring to see if I can pull something that feels good off to ease the off-ramp from Rails and on-ramp to Hanami. I still have a lot to figure out about Hanami but I think this would certainly help me and the next person coming from Rails-land get acclimated to the weather here . Thoughts? Is it an unreasonable idea ?
As someone who is also coming from a Rails background, and who mentors juniors, having on-ramps from Rails to Hanami feels very reasonable and is something that is welcomed! See the response here: A Ruby Ecosystem for Web Apps - #2 by cllns
I wonder if V0.5/V1 would simply be writing adapter code so that ActiveStorage can be slotted into a Hanami app; akin to how I imagine it’s possible to use ActiveRecord as the DB layer in a Hanami app. Then, it’s avoiding Yet Another Solution, and the “next step” could be Shrine
Which is not to say “don’t write an ActiveStorage-style gem for Rack apps!” (If you want to!!)
More, that from what I’m starting to understand, “Hanami’s ethos is modularity, so if you’re trying to use ActiveStorage…what’s involved with just using ActiveStorage”
unfortunately there’s a lot involved with trying to just use ActiveStorage, everything from ActiveJob to ActiveSupport to ActiveRecord. I’m not sure it’s just that easy to use it vs writing something custom for Hanami.
Shameless plug but I’ve written how to integrate Shrine with Hanami, maybe you have seen it somehow Hanami Shrine - file handling in Hanami | 2N and comparing the process I described there, we are pretty close. To condense the steps I described there:
Add the gem
Setup provider (this includes env for storage, it was s3 in my case for non-test, and file system for test) and settings (to map the env values)
Add a column to database (migration) - sure, there is no way right now to do this with command, but its literally one line in migration file
Setup a ImageUploader - yes this is an extra step that derives from your described desired process but its sort of a thing you set up once and forget about it later on
Enable the association (done in a repo method that allows for attaching + a struct for the image)
View + params in action to handle form
The url is accessible from the object shrine gives you
So the process you are talking about I think is (mostly) already there, accessible through a proper Shrine integration. It might be a bit more work than something completely native, but native tools for those sort of things come with a certain baggage. One of the reasons I dislike ActiveStorage is how it is very bound to rails and has a non-intuitive DSL and interface (and requires a lot more in database than shrine does). Tool for this for hanami, would also have to enforce some things, which in Hanami I think is harded than in Rails, cause Rails has a rather well defined “rails-way” which active storage adheres to. I do not think Hanami has a “hanami-way” which is why I really like it, as it has a more hands-off approach to certain solutions, file storage and upload being one of them.
The one thing that I would like to maybe see improved in this matter is better native file handling in params in views, but that is separate from a tool that handles storage.
I did see it! It was one of the reasons I decided that it was too much for me to do in every single application, over and over . I build dozens of apps each year and doing that over and over and over is not for me
.
. Thoughts? Is it an unreasonable idea 
?
. I build dozens of apps each year and doing that over and over and over is not for me