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

Makes SparkForm internal attributes non-enumerable #220

Closed
wants to merge 1 commit into from
Closed

Makes SparkForm internal attributes non-enumerable #220

wants to merge 1 commit into from

Conversation

Max13
Copy link
Contributor

@Max13 Max13 commented Jul 4, 2018

Currently, when looping SparkForm's properties or submitting forms cause errors, busy and successful internal properties to be shown/submitted as well, potentially overriding a form's input.

These changes shouldn't break anything.

Currently, when looping SparkForm's properties or submitting forms cause `errors`, `busy` and `successful` internal properties to be shown/submitted as well, potentially overriding a form's input.
@taylorotwell taylorotwell requested a review from themsaid July 5, 2018 13:57
@themsaid
Copy link
Member

themsaid commented Jul 5, 2018

Can you please explain in more detail what this PR is trying to solve? I don't seem to get the problem? Can you please share code?

@themsaid
Copy link
Member

themsaid commented Jul 6, 2018

Ping @Max13

@Max13
Copy link
Contributor Author

Max13 commented Jul 6, 2018

When a SparkForm is submitted with Ajax, it contains the 3 keys I've mentioned. Which prevent any form to use them.

I think these keys are not supposed to be sent anyway, are they?

For instance, a form containing a checkbox[v-model="successful"] would be either overridden by the internal successful key (when checked) or falsely sent if unchecked.

Do you still need code?

@taylorotwell
Copy link
Member

Maybe you could just rename your form variables to something else?

@Max13
Copy link
Contributor Author

Max13 commented Jul 6, 2018

@taylorotwell Of course I and everybody else can, but I just thought that it would be a good idea to make them non enumerable to avoid this behavior

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

Successfully merging this pull request may close these issues.

3 participants