The "Form" name is misleading
zavan opened this issue · 4 comments
I think when we say "form object" (at least in rubyland, from what I see in other form object projects) we mean an object that takes simple input and (using other objects by composition, keeping separation of concerns in mind), prepares (coerce, strip, etc) and validates the input. And that's it.
That said, an object (ROM::Model::Form) that uses a form (input + validation blocks) to prepare and validate the data, and then performs an action by orchestrating message passing between other objects (the commit! method orchestrating ROM commands) and using the prepared and validated input, as ROM::Model::Form does, looks much more like an Operation, Service Object, Interactor, whatever you call these kind of objects, than just a Form.
A good example, that is close to what a ROM::Model::Form does, is a Trailblazer::Operation (from the trailblazer project), it uses a form object (called a contract there) to prepare and validate the input, and then act upon it within the perform method.
I think calling this object Interactor or Operation would make much more sense (and that it should be extracted to a separate gem, because it has a lot of potential).
Also, I love using ROM, and thank you for all your hard work in trying to make the ruby community a better place!
I think when we say "form object" (at least in rubyland, from what I see in other form object projects) we mean an object that takes simple input and (using other objects by composition, keeping separation of concerns in mind), prepares (coerce, strip, etc) and validates the input. And that's it.
From what I've seen all "Form object" abstractions also included the persistence logic, so I just cargo-culted that ¯_(⊙_ʖ⊙)_/¯
ROM::Model::Form (..) looks much more like an Operation, Service Object, Interactor, whatever you call these kind of objects, than just a Form.
I'm not going to argue here, FWIW I don't like classes with noun names in general, so Form sounds equally bad as Interactor for me :)
I think calling this object Interactor or Operation would make much more sense (and that it should be extracted to a separate gem, because it has a lot of potential).
I don't have an opinion to be honest, I actually only added this abstraction to make it possible to use ROM in a railsy way, and it was a mistake. I compose simple objects with clear responsibilities rather than trying to come up with some generic concepts like "Operation" or "Interactor" and esp "Service Object". Those things don't mean anything to me because they can be anything. I found great beauty in simple object composition that doesn't use any ambiguous concepts.
This means rather than using "form object" and "operation" or whatever else I prefer to have a couple of standalone and simple objects that I can compose together in a functional way. It's one of the reasons why I built transflow gem recently to simplify this process and use some conventions :)
The only missing piece of the puzzle (for me) here is a nice validation library that would follow similar design patterns like rom components. The one in rom-model is not that, yet :/
I pretty much just want to do this:
persist_user = preprocess_input >> validate_user_input >> persist_user_input >> map_persisted_data_to_whatever_i_want
persist_user.call(user_input)
As opposed to some huge classes with gigantic DSLs :)
Also, I love using ROM, and thank you for all your hard work in trying to make the ruby community a better place!
Ah this makes me so happy :) <3
The only missing piece of the puzzle (for me) here is a nice validation library that would follow similar design patterns like rom components. The one in rom-model is not that, yet :/
@solnic is this missed piece became https://github.com/dry-rb/dry-validation ?
@maximderbin of course :)
we're deprecating the entire form component of rom-rails, so I'm going to close this.