- Mar 2021
I'm kinda stuck at the moment, going around in circles. Everything is really heavily coupled. I would like to get to the point where no load is called from within processors, but i'm not sure if that's possible. Currently the API and the caching strategies are fighting me at every step of the way. I have a branch where i'm hacking through some refactoring, no light at the end of the tunnel yet though :(
- Feb 2021
@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
- pointing out gaps/downsides/cons in competition/alternatives
- hard to understand
- too complicated
- switching/migrating to something different
- recommended software
- I agree
- reform (Ruby)
- recommended option/alternative
- evaluating software options
- too coupled/dependent
The assert method is used by all the other assertions. It pushes the second parameter to the list of errors if the first parameter evaluates to false or nil.
Seems like these helper functions could be just as easily used in ActiveRecord models. Therefore, they should be in a separate gem, or at least module, that can be used in both these objects and ActiveRecord objects.
- too coupled/dependent on
- this is an orthogonal concern; it should be separate from that rather than part of / coupled with that
- do one thing and do it well
- helper functions
- why create/reinvent a new/different way to do it instead of reusing existing way?