Material-design-lite: State of switches should automatically reflect state of the underlying input's "checked" property

Created on 3 Sep 2015  Â·  10Comments  Â·  Source: google/material-design-lite

At present modification of the .checked property of the underlying input of switches (and perhaps other similar components, e.g. radio and checkboxes, I haven't checked, pun intended) doesn't automatically result in an update to the presentation layer - instead a manual call to .MaterialCheckbox.check() or .MaterialCheckbox.uncheck() is needed.

I propose that this shouldn't be the case, MDL should progressively enhance the underlying input by listening for changes to the value of .checked and automatically fire the appropriate function to update the visual state, which would allow existing code / code from other libraries to be used without modification and would avoid confusing new users of MDL.

Checkbox Switch research

Most helpful comment

It took me about 2 hours of googling to figure out how to check the state of a switch. The JS documentation is absolutely atrocious, and essentially nonexistent. There is ZERO MENTION of how to actually use these switches, except for the HTML itself. I seriously regret ever trying to use this framework. You should be ashamed, Google.

For anyone looking for the answer to what seems like such an obvious use-case, the following worked for me, and will return a true or false value:

YourSwitch.parentElement.MaterialSwitch.inputElement_.checked

All 10 comments

I agree that deviating from the “Standard API” – if you will – is rather suboptimal. That’s one of the lessons we learned so far. We could try to incorporate that without it being a BC by keeping the old API but adjusting the styles, but I suspect it’s not as easy as it sounds so we might have to push this back to v2. We’ll investigate that further.

This isn't feasible without observers. If a developer changes the checked property using JS, no event is fired. It needs to be manually ran by developers to have any event handlers fire off. This is why we have the internal API for handling these things and updating the presentation.

@Garbee I was wondering if we can implement this using CSS only (i.e. using the [checked] selector), but I guess that would require a BC.

Yes, BC break there for sure. But, we also have to think about error handling, which still requires JS to function with the way we need to do markup structure. So, that complicates things further if you check something and the UX updates, but it goes into an invalid state and you don't call our checkValidity method to handle updating the UX for that.

We need to write up an example component and see how things interact here.

Garbee at least sample like i just try here would very help full.

http://codepen.io/anon/pen/QjwKQR.

I not much knew javascript oop but when i open phpstorm and see green color unlock then i know what to test like checkDisabled, checkToggleState,disable,enable ,on,off.

** sorry if i got wrong idea of the topic..

Yea, I know the code to make it function now. I meant we would need to mockup an example of the modified methodology proposed and play around with that to see how it functions.

Are we still looking at this? As far as I can tell, this is not doable cleanly without observers (and we should avoid pulling observer polyfills into MDL).

Doing this with CSS only would significantly constrain our DOM structure for switches, as we'd need to build rules in the form .mdl-switch__input[enabled] <something>. Because of this, <something> would have to be either a child (we don't want to do that, sticking custom stuff inside native elements) or a successor. The latter would mean something like:

<input class="mdl-switch__input" id="switch1"></input>
<label class="mdl-switch" for="switch1">[...]</label>

which is not exactly ideal, since we have the top level element of the switch as a sibling to one of its parts.

IMO, we should stick to having an API in v2, but just make it more similar to the native platform, e.g.:

foo.MaterialSwitch.checked = true;

Constraining markup heavily is certainly not a good idea. People will try to pull things out and it will not work right then complaining comes in the other way.

+1 to just verifying the JS API is available and well documented (as we are already planning.)

this work for me

$('#label').addClass('is-checked');
or
$('#label').removeClass('is-checked');

It took me about 2 hours of googling to figure out how to check the state of a switch. The JS documentation is absolutely atrocious, and essentially nonexistent. There is ZERO MENTION of how to actually use these switches, except for the HTML itself. I seriously regret ever trying to use this framework. You should be ashamed, Google.

For anyone looking for the answer to what seems like such an obvious use-case, the following worked for me, and will return a true or false value:

YourSwitch.parentElement.MaterialSwitch.inputElement_.checked

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tleunen picture tleunen  Â·  5Comments

ktodyruik picture ktodyruik  Â·  5Comments

samuelcarreira picture samuelcarreira  Â·  4Comments

itisparas picture itisparas  Â·  3Comments

J2TEAM picture J2TEAM  Â·  3Comments