Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected validation behavior on filters with validators #574

Open
mogman1 opened this issue May 30, 2024 · 3 comments · May be fixed by #582
Open

Unexpected validation behavior on filters with validators #574

mogman1 opened this issue May 30, 2024 · 3 comments · May be fixed by #582

Comments

@mogman1
Copy link

mogman1 commented May 30, 2024

Given the following interaction, I would expect behavior around validations to be:

class Foo < ::ActiveInteractin::Base
  string :bar
  validates :bar, presence: true
end

x = Foo.new
x.valid? == false # it's actually nil
x.bar = "baz"
x.valid? == true # unfortunately it's still nil

In each test, rather than the boolean expected, I'm seeing nil returned. In the first example, that's at least still falsey, but it's not the behavior I'd expect from a typical failed validation using vanilla ActiveModel validations. In the second example that should cure the validation problem, but I still see nil.

@AaronLasseigne
Copy link
Owner

I consider falsey values sufficient. Interactions aren't really intended to be rerun. What's the valid use case for rerunning one?

@mogman1
Copy link
Author

mogman1 commented Nov 23, 2024

I uncovered this while messing around in the rails console and getting confused when even after fixing a validation error, I was still getting a falsey value. I thought something else was going on before I finally realized it was a bug.

I guess my argument would be that since this is meant to behave like ActiveModel with respect to its validations, and since ActiveModel validations are curable, then ActiveInteraction's should be as well. That way it'll behave like you'd expect. I'd be happy to resurrect my PR that addresses this.

@mogman1 mogman1 linked a pull request Dec 1, 2024 that will close this issue
@mogman1
Copy link
Author

mogman1 commented Dec 1, 2024

I've reopened my original PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants