-
Notifications
You must be signed in to change notification settings - Fork 75
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
Allow passing { parse: true } to set #109
base: master
Are you sure you want to change the base?
Conversation
parse: true
to set
Code looks fine, tests are valid, so +1 from me, as it's only added value and no potential risk. Thanks @jackboberg! |
2a6df94
to
a105cdc
Compare
a105cdc
to
11e0835
Compare
Hey guys, are you planning to merge this in a near future? |
@@ -1542,74 +1542,31 @@ test('#68, #110 mixin props should not be deleted', function (t) { | |||
t.end(); | |||
}); | |||
|
|||
test('#114 setOnce allows values to be set once and only once', function (t) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jackboberg It looks like a few tests are being removed here. Is that intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, that's a rebase gone awry...I'll get it fixed up tonight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-rebased, thanks for the note.
11e0835
to
88289db
Compare
Gah, apparently I cannot comment on lines that you didn't edit. At a glance I'm reasonably sure we'll need to remove the parse in line 14, otherwise on new model initialization with |
passing `{ parse: true }` will trigger during `set`
Removed the constructor call. Would you like me to add a specific test to ensure parse is only called once? |
I think as long as the other tests pass that's fine IMO Philip Roberts
|
I had cherry-picked this change into our app, but just discovered an issue with it. I'm storing Amp.States in a Backbone.Collection, and if you call Overall, the current pattern is that whoever owns the State instance is responsible for doing:
BB.Collection does that already, it looks like Amp.Collection does that as well, and in both cases they then pass in the same Ultimately, I think this change is useful in the case where you're calling |
Closes #106 #84