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

Глобальный апдейт для видов в попапе #603

Open
eljusto opened this issue May 31, 2016 · 5 comments
Open

Глобальный апдейт для видов в попапе #603

eljusto opened this issue May 31, 2016 · 5 comments

Comments

@eljusto
Copy link

eljusto commented May 31, 2016

Попапы сейчас вне ноды app и глобальный апдейт на них не работает.
Кажется, правильным решением было бы наличие метода rootUpdate, который выполнял апдейт на корневой для текущего вида ноде.

А вообще, вьюха, по-хорошему, не должна уметь обновляться по-разному, в зависимости от её положения.

Своё решение есть в композе почты

ns.View.prototype.composeUpdate = function() {
    if (this.info && !this.info.isCollection) {
        this.invalidate();
    }

    if (this.isVisible()) {
        this.getModel('compose-state').trigger('ns-model:compose:update');
    } 
};
[...]
// событие ns-model:compose:update ловится на корневом виде композа
_composeUpdate: function() {
                if (!this.isVisible()) {
                    return;
                }

                this.update();
            },
@vitkarpov
Copy link
Member

Попапы сейчас вне ноды app и глобальный апдейт на них не работает

Может имеет смысл корневой вьюшкой делать body, а не #app? :)

@vitkarpov
Copy link
Member

Мне кажется, что #app был захардкожен по историческим причинам.

@Katochimoto
Copy link
Member

Katochimoto commented Jun 1, 2016

не, тут смысл в другом
надо чтобы можно было разделять глобальные объекты
а в идеале не знать про глобальный апдейт (где он должен быть выполнен, какой текущий корневой вид)

кейс связан с особенностью разработки например попапов.
для уменьшения негативного влияния глоб апдейта и для ускорения отрисовки, они вынесены из структуры проекта и не участвуют в глоб апдейте.
при этом сами могут содержать сложные составные лайауты.
так же лайауты и виды внутри попапа могут переиспользоваться вне попапа.

поэтому хочется чтобы ап сам решал на каком верхнем предке следует выполнить апдейт.

@chestozo
Copy link
Member

+1
Кейс такой:

  • промо-попап, он вне app, у него своя жизнь, рисуется он через updateByLayout
  • что-то происходит и мы хотим перерисовать какой-то из видов внутри попапа
  • запускаем где-то внутри вида ns.Update с флагом ASYNC
  • в это время кто-то запускает глобальный ns.Update, который отменяет все ASYNC-и

Это ок когда update-ы внутри app
А тут у нас получается в попапе свои update-ы и они не должны отменяться update-ами app-а.

@chestozo
Copy link
Member

chestozo commented Jun 16, 2016

Возможно при запуске updateByLayout стоит все виды начиная с корневого помечать как-то (типа view.domain = 'promo') и тогда во время отмены udpate-ов не трогать update-ы из других песочниц.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants