Cache result of validation once outcome is done

[lulalala]

This is just throwing some ideas.

Currently, if we call outcome.valid?, it would re-evaluate all the validations again.

If one validation is not idempotent, for example checking if it is run on weekdays, it can results in inconsistency between outcome object and its valid? results. (Say we run it on Friday 23:59 and then the controller gets to check its validity on Saturday 00:01)

Would it makes sense to provide some caching mechanism, so that once outcome is done, outcome's error result can be cached, so that validations won't be run again?

[lulalala]

Just realized that there already exists some caching, checking for @_interaction_valid.

It's just that if interaction fails during validation phase, result= is never called, thus that will not be assigned.

Would something like this work?

    def valid?
      if instance_variable_defined?(:@_interaction_valid)
        return @_interaction_valid
      end

      @_interaction_valid = super
    end

==UPDATE==

The above would not work, if validations are successful, but some errors happens during execute, it would result in a failed yet valid outcome. I guess the way to do it would be like this:

    def run # rubocop:disable MethodLength
      if !valid?
        @_interaction_valid = false
        return
      end

This way if it validates successfully, the results won't be cached yet, allowing it to be set after execute.

[AaronLasseigne]

So it's valid and you get an outcome but then when you call valid again it's failing?

[lulalala]

@AaronLasseigne actually it is the opposite: only when validation fails, would calling valid? reevaluate it again. So it can validate to failure, and we call valid? later and get true back.

[AaronLasseigne]

For a test I used:

class I < ActiveInteraction::Base
  VALID = [false, true].cycle

  validate do |interaction|
    interaction.errors.add(:base, 'failed') if !VALID.next
  end

  def execute; end
end

I was able to cache the result by changing valid?.

    def valid?(*)
      if instance_variable_defined?(:@_interaction_valid)
        return @_interaction_valid
      end

      valid = super
      self.result = nil unless valid
      valid
    end

This seems to have fixed the issue.

[AaronLasseigne]

@tfausak we let people modify the value of an input but it doesn't change the result attached to the outcome. Do you remember why we allow that?

[tfausak]

I don't remember why we do that.

[AaronLasseigne]

After thinking about this some I think it's a great idea. We should always cache the result and we shouldn't let people modify the inputs. That makes the whole process more immutable. I think this would probably require a major version bump though. We have a few other things that also need a major bump so maybe it's time.

[tfausak]

Makes sense. We'll have to make sure we don't mess up using interactions in forms if they're immutable.

[AaronLasseigne]

@lulalala I believe this will fix the issue you were having. Once run (or run!) is called and an outcome is produced, the result and the validity of that outcome are immutable.

It'll be part of the 4.0.0 release.

[lulalala]

I just met another bug, where I have a callback, and calling valid? caused that callback to be called twice. The 4.0.0 branch fixed this. Cheers!

[AaronLasseigne]

I decided to go ahead and release this as a bug fix in v3.6.2.