Add setAttributes for View

[paulfalgout]

Users may decide to set className, id, or attributes with a function such that the values can change based on the view's state or model.

In general the user is expected to update these values manually once the element is set. It isn't terribly hard to manage className or other attributes directly, but there is a little bit of logic regarding className and id overriding the attributes hash.

This simplifies answering how to update the el's attributes after initialization.

[paulfalgout]

These changes to the quotes here fix a linter warning

[blikblum]

Maybe rename to updateAttributes ?

[akre54]

I don't love that this changes the method signature of setAttributes. What if instead we allowed both setAttributes(attrs) and setAttributes(), checking if an attrs object was passed in and then falling back to the old behavior if not?

Admittedly I've never had a use case for either, but I can see arguments both ways.

[paulfalgout]

Yeah I was on the fence about that very issue originally having one function and renaming _setAttributes.

If setAttributes handles both signatures should we keep_setAttributes?

[akre54]

The underscored version is for "hooks" that do the actual DOM manipulation (see #3003).

On Mon, Mar 20, 2017, 22:19 Paul Falgout ***@***.***> wrote: Yeah I was on the fence about that very issue originally having one function and renaming _setAttributes. If setAttributes handles both signatures should we keep_setAttributes? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4128 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA42KGmR_xqpLB2NQ6t7p9SiZPgohhwmks5rnzO2gaJpZM4Mhu4d> .

-- Adam K (mobile)

[paulfalgout]

Alright updated.

TBH I've never really needed this before either.. but I recently consulted on a project doing a lot of filling in attributes from an endpoint that configures the views. The data isn't super consistent and the logic they were using to handle it was intense (certainly unnecessarily) when really all they wanted to do was re-run what was happening initially. Easy enough to implement myself, but I think they would have avoided this had their been the method available.

Won't be heart broken either way, but it seems reasonable to me.

[akre54]

So I'm gonna be a weak close on this. It's easy enough to write your own plugin / base view if you really need it, and no sense adding complexity to the API for the folks that don't.