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

Rules not exported after non-static rule #278

Open
jtojnar opened this issue Oct 3, 2021 · 0 comments
Open

Rules not exported after non-static rule #278

jtojnar opened this issue Oct 3, 2021 · 0 comments
Milestone

Comments

@jtojnar
Copy link
Contributor

jtojnar commented Oct 3, 2021

Version: 3.1.3

Bug Description

Since 1592cf6, no rules after a callback rule are passed to the frontend.

I understand that this is to prevent conflict between filters (which are just impure rules) and other rules but it leads to confusing behaviour, where rules suddenly terminate from frontend point of view, even if the callback is just a pure function.

Steps To Reproduce

test('', function () {
	$form = new Form;
	$input = $form->addText('text');
	$input->addRule(function ($input) {
		return true;
	});
	$input->addRule(Form::EMAIL);
	Assert::same([
		['op' => ':email', 'msg' => 'Please enter a valid email address.'],
	], Helpers::exportRules($input->getRules()));
});

Expected Behavior

I think we should give callbacks passed to addRule a benefit of a doubt (that they might be pure) and not terminate the rule export.

But yeah, I understand the paranoid point of view (all functions are potentially effectful/impure and we cannot trust them not to modify the control) since PHP cannot distinguish pure and effectful functions.

Possible Solutions

  • We could add isFilter/impure property to Rule, set it to true in addFilter, and terminate export only for impure rules.
  • The behaviour could be further emphasised in docs and the hack would be recommended:
    $this->addCondition(true) // not to block the export of rules to JS
jtojnar added a commit to jtojnar/entries that referenced this issue Oct 3, 2021
Due to this extremely confusing change, client side validation for custom rules on category field got broken:

nette/forms@1592cf6

Let’s apply the hack from the commit.

Opened an issue: nette/forms#278
@dg dg added this to the v4.0 milestone Oct 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants