11 Matching Annotations
- Feb 2021
-
github.com github.com
-
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>
and that
If the value does not match, it will call
find
on 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.
Tags
- ActiveRecord
- good example
- why is it better?
- first sighting
- different way of thinking about something
- expected behavior
- reusability
- reasonable defaults
- useful
- supersedes
- reasonable behavior
- polymorphism
- avoid duplication
- newer/better ways of doing things
- different way of solving/implementing something
- business logic
- interesting idea
- good idea
- active_interaction
- software development: code organization: where does this code belong?
Annotators
URL
-
-
github.com github.com
-
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.
-
-
github.com github.com
-
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.
-
-
github.com github.com
-
@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
Tags
- too complicated
- I agree
- reform (Ruby)
- evaluating software options
- flexibility
- pointing out gaps/downsides/cons in competition/alternatives
- too coupled/dependent
- hard to understand
- recommended option/alternative
- recommended software
- active_interaction
- switching/migrating to something different
Annotators
URL
-