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

Backbone/jQuery style alternative notation for setState/setProps #2189

Closed
Ahrengot opened this issue Sep 13, 2014 · 3 comments
Closed

Backbone/jQuery style alternative notation for setState/setProps #2189

Ahrengot opened this issue Sep 13, 2014 · 3 comments

Comments

@Ahrengot
Copy link

Being able to do this.setState('key', value, callback); when you're only changing a single item would make things a little more readable in my opinion. Thoughts?

When the title says Backbone/jQuery style notation I'm referring to $('#target').css('color', 'red') being an alternative to $ '#target').css({color: red}) in jQuery and model.set('key', value) being an alternative to model.set({key: value}) in Backbone

@oriSomething
Copy link

i actually think it makes it less readable, because you need to ask yourself if you see something like this: this.setState(a, b) without the problematic naming for the example, what are a and b. is a an object? a key? because of that i also prefer when i use backbone / jQuery writing model.set({ key: value })

@chenglou
Copy link
Contributor

Old issue: #175

I've come to believe that it's better left this way. You've got one way to do things and setState({a: b}) is just as concise as the shorthand.

Somewhat related: with immutable collections, it'll probably be setState(wholeStateObj) all the time. setState({a: b}) would mean your new state has nothing but {a: b}. Under this situation setState('a', b) doesn't make much sense anymore.

@zpao
Copy link
Member

zpao commented Sep 15, 2014

Thanks for finding that @chenglou. There was also #282 where somebody made this work.

I think at this point, we're going to wontfix it again. I do understand the desire but I also think an explicitly (and consistently) typed API is more readable and usable long term than something more polymorphic like this. This is the direction we've tried to move with our code and I think we'll stick with it.

There hasn't been a strong need for this and it's really only people making the transition from Backbone that have even asked. But if we do add this, I think we'll want to do it with its own API, not reuse setState like this.

@zpao zpao closed this as completed Sep 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants