Порядок событий при изменении модели #165

Merged
merged 1 commit into from Oct 15, 2013

Conversation

Projects
None yet
2 participants
@edoroshenko
Contributor

edoroshenko commented Oct 9, 2013

Сейчас наши супермодельки при .set кидают пачку событий.
Сначала идут события с jpath типа ns-model-changed.{jpath}, а затем просто ns-model-changed.
ns.Update завязан на то, что при изменении модели вьюшка автоматом инвалидируется. Т.е. ns.View честно подписывается на ns-model-changed для инвалидации.
Если предприимчивый разработчик подпишется на ns-model-changed.{jpath}, да ещё и сделает там page.go, то Update начнётся до того, как ns.View, зависящий от этой модели, проинвалидируется. В такой ситуации возможны баги при рендеринге, обновлении, перерисовке итд.

Что я сделал: я поменял порядок событий. Сначала ns-model-changed, затем кастомные ns-model-changed.{jpath}. Так мы почти гарантируем, что обработчики, висящие на change у модели выполнятся после обработчика от ns.View.

Рассматривал и другие способы решения:

  • добавить другое событие, например ns-model-set
  • запускать обработчики с нулевым таймаутом.
    Первый способ показался наиболее адекватным.

Тесты работают.

cc @doochik @chestozo

@chestozo

This comment has been minimized.

Show comment
Hide comment
@chestozo

chestozo Oct 11, 2013

Member

Вообще, мне кажется, надо продумать какие-то рекомендации для обработки событий модели вьюхами.
А именно: кто и когда должен вызывать ns.page.go().
Потому что сейчас можно наподписываться на разные события и навызывать ns.page.go() дофига где.
А по факту хочется их группировать и выполнять однажды.

Или ещё альтернативный вариант:

var _updates = {};
var callPageGo = function(model, force) {
  var key = model.getKey() + ':' + model.getVersion();
  if (key in _updates && !force) {
    return;
  }
  _updates[key] = true;
  ns.page.go();
};
Member

chestozo commented Oct 11, 2013

Вообще, мне кажется, надо продумать какие-то рекомендации для обработки событий модели вьюхами.
А именно: кто и когда должен вызывать ns.page.go().
Потому что сейчас можно наподписываться на разные события и навызывать ns.page.go() дофига где.
А по факту хочется их группировать и выполнять однажды.

Или ещё альтернативный вариант:

var _updates = {};
var callPageGo = function(model, force) {
  var key = model.getKey() + ':' + model.getVersion();
  if (key in _updates && !force) {
    return;
  }
  _updates[key] = true;
  ns.page.go();
};
@edoroshenko

This comment has been minimized.

Show comment
Hide comment
@edoroshenko

edoroshenko Oct 11, 2013

Contributor

Да, рекомендации точно нужны. У меня уже есть несколько грабель, про которые я готов рассказать.
Про группировку - мы к этому вобщем-то давно уже пришли. Там наша кастомная логика.

Contributor

edoroshenko commented Oct 11, 2013

Да, рекомендации точно нужны. У меня уже есть несколько грабель, про которые я готов рассказать.
Про группировку - мы к этому вобщем-то давно уже пришли. Там наша кастомная логика.

edoroshenko added a commit that referenced this pull request Oct 15, 2013

Merge pull request #165 from yandex-ui/model-eventsorder
Порядок событий при изменении модели

@edoroshenko edoroshenko merged commit 90e2155 into master Oct 15, 2013

1 check passed

default The Travis CI build passed
Details

@edoroshenko edoroshenko deleted the model-eventsorder branch Oct 15, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment