5 ms·

Have you looked at ActiveModel::Attributes ? That coupled with ActiveModel::Model makes for simple form objects quite nicely. Also, you can write your _own_ Act

Have you looked at ActiveModel::Attributes ? That coupled with ActiveModel::Model makes for simple form objects quite nicely. Also, you can write your _own_ ActiveModel::Type so you can require that a particular attribute is a particular (business) model. I've been finding it a very nice way to write form objects. It's a bit dated now, but, I did a short presentation for my local ruby meetup and the slides are here [1] 1. https://slides.com/patrickdavey/rails-5-2-attributes-api#/25 https://slides.com/patrickdavey/rails-5-2-attributes-api#/25

hakunin 4y ago
Thanks for the suggestion. I actually explored switching to Attributes for a new Rails app, but 3 reasons made me come back to portrayal gem: 1) attributes don't support defaults. 2) I prefer not to set types on form object attributes, since they are supposed to deal with messy user input. Instead I lean on validations. And 3) I like read-onlyness, freeze, equality, duplication, and introspection features of portrayal gem.
- patrickdavey 4y ago
  Attributes do support defaults. You can absolutely do: attribute :my_time_at, :datetime, default: -> { Time.now } attribute :persisted, :boolean, default: false What I like about the types is that it will automatically coerce the messy user data automatically (this is what AR is doing under the hood anyway right?), you can just be more intentional about it. Anyway, glad you're happy with portrayal :) I definitely agree with you on the "freeze, read-onlyness" etc. being good things to have!
  - hakunin 4y ago
    Ah, I accidentally lied by trying to reconstruct a vague memory, apologies. Now I'm remembering it in more detail. It wasn't lack of defaults, it was handling of defaults. Portrayal does a couple of smart things like evaluating defaults in a specific order in the correct context (while still only evaluating once), such that this becomes possible: keyword :name keyword :greeting, default: proc { "Hello, #{name}" } I like being able to do this. (This also works gracefully with subclassing.) The coercion argument is good, but I'm not a fan of doing it implicitly. (This was the real counter-argument I should've made). I prefer to have a single place where input is entirely processed, such as a `from_params(params)`-style constructor. In that constructor you could either coerce, or do anything else with the input prior to passing it through to `.new`.

hakunin 4y ago

Thanks for the suggestion. I actually explored switching to Attributes for a new Rails app, but 3 reasons made me come back to portrayal gem: 1) attributes don't support defaults. 2) I prefer not to set types on form object attributes, since they are supposed to deal with messy user input. Instead I lean on validations. And 3) I like read-onlyness, freeze, equality, duplication, and introspection features of portrayal gem.

patrickdavey 4y ago
Attributes do support defaults. You can absolutely do: attribute :my_time_at, :datetime, default: -> { Time.now } attribute :persisted, :boolean, default: false What I like about the types is that it will automatically coerce the messy user data automatically (this is what AR is doing under the hood anyway right?), you can just be more intentional about it. Anyway, glad you're happy with portrayal :) I definitely agree with you on the "freeze, read-onlyness" etc. being good things to have!
- hakunin 4y ago
  Ah, I accidentally lied by trying to reconstruct a vague memory, apologies. Now I'm remembering it in more detail. It wasn't lack of defaults, it was handling of defaults. Portrayal does a couple of smart things like evaluating defaults in a specific order in the correct context (while still only evaluating once), such that this becomes possible: keyword :name keyword :greeting, default: proc { "Hello, #{name}" } I like being able to do this. (This also works gracefully with subclassing.) The coercion argument is good, but I'm not a fan of doing it implicitly. (This was the real counter-argument I should've made). I prefer to have a single place where input is entirely processed, such as a `from_params(params)`-style constructor. In that constructor you could either coerce, or do anything else with the input prior to passing it through to `.new`.