Событие click
на checkbox
(и radio
) странно и сбивает с толку.
В принципе, это происходит в момент взаимодействия с мышью, до того, как щелчок заставил флажок изменить свое состояние. Следовательно, должна быть возможность return false
или event.preventDefault
отменить действие по умолчанию для внесения этого изменения состояния. В этом случае состояние флажка никогда не должно касаться.
Однако в большинстве браузеров это не так. Из некоторой исторической причуды, восходящей к древнему Netscape, свойство checked
флажка во время обработчика события click
фактически является новым значением. Само событие click уже приводит к изменению состояния флажка. Затем, если вы запретите действие по умолчанию (return false
), браузер скажет: «К сожалению, из-за этого изменения никогда не было», и активно вернет флажок обратно к его старому значению .
Это означает, что если вы намеренно установили состояние флажка из сценария в обработчике кликов, это значение будет потеряно из-за странной попытки браузера повернуть время вспять при изменении первоначального клика.
Итак, нелогично, если не набрать return false
и предотвратить действие по умолчанию, это фактически заставит браузер меньше вмешиваться! Другое исправление:
setTimeout(Controller.updateView, 0);
вместо вызова updateView
непосредственно в обработчике кликов. Это дает браузеру возможность перевернуть его состояние до того, как перезапишет его из модели. Вы даже можете поместить весь обработчик события, кроме return false
, в 0-тайм-аут.
Теоретически правильным решением было бы использовать onchange
вместо onclick
. Это событие однозначно происходит после изменения состояния, поэтому вам не нужно беспокоиться об этой странности и совместимости браузера. Проблема с onchange
в том, что IE запускает его не так быстро, как следовало бы; он ожидает фокусировки, чтобы переместиться из флажка перед выстрелом, как при вводе текста. Так что, по крайней мере, в этом браузере для согласованности вам понадобится вместо этого 0-timeout-on-click.