- Feb 2021
Record filters allow you to require an instance of a particular class (or one of its subclasses) or a value that can be used to locate an instance of the object. If the value does not match, it will call find on the class of the record. This is particularly useful when working with ActiveRecord objects.
ActiveInteraction plays nicely with Rails. You can use interactions to handle your business logic instead of models or controllers.
> RecordInteraction.run!(encoding: 'ascii') => #<Encoding:US-ASCII>
Makes use of the fact that you can do:
main > Encoding.find('ascii') => #<Encoding:US-ASCII>
If the value does not match, it will call
findon the class of the record.
recommended by (also my first sighting of it): https://hyp.is/oDsgQHF0Eeu7kEvGAmpHeQ/github.com/rails/rails/pull/19709
Why is all this interaction code better? Two reasons: One, you can reuse the FindAccount interaction in other places, like your API controller or a Resque task. And two, if you want to change how accounts are found, you only have to change one place.
Pretty weak arguments though...
- We could just as easily used a plain object or module to extract this for easy reuse and having it in only one place (avoiding duplication).
This probably looks a little different than you're used to. Rails commonly handles this with a before_filter that sets the @account instance variable.
- why is it better?
- expected behavior
- software development: code organization: where does this code belong?
- different way of solving/implementing something
- business logic
- reasonable behavior
- interesting idea
- avoid duplication
- different way of thinking about something
- newer/better ways of doing things
- good idea
- first sighting
- reasonable defaults
- good example
For now I've worked around this by putting all the key-value pairs into an array before passing them into the interaction, then re-building the hash inside the interaction. It works, but it requires some extra code
I'm sure there will be a few other people out there who eventually want something like this, since Interactions are actually a great fit for enforcing consistency in data structures when working with a schemaless NoSQL store, but obviously it's still a bit of a niche audience.
- less-than-ideal workarounds
- smaller/minority/specific/niche audience
- type safety
- where it shines / best application
- there is a need/niche for it
array :translations do hash do string :locale string :name end end array inputs can only have one input nested underneath them. This is because every element of the array must be the same type. And the inputs nested inside arrays cannot have names because they would never be used.
@adisos if reform-rails will not match, I suggest to use: https://github.com/orgsync/active_interaction I've switched to it after reform-rails as it was not fully detached from the activerecord, code is a bit hacky and complex to modify, and in overall reform not so flexible as active_interaction. It has multiple params as well: https://github.com/orgsync/active_interaction/blob/master/spec/active_interaction/modules/input_processor_spec.rb#L41
I'm not sure what he meant by:
fully detached from the activerecord I didn't think it was tied to ActiveRecord.
But I definitely agree with:
code is a bit hacky and complex to modify
- hard to understand
- switching/migrating to something different
- reform (Ruby)
- I agree
- recommended option/alternative
- too coupled/dependent
- too complicated
- recommended software
- evaluating software options
- pointing out gaps/downsides/cons in competition/alternatives