Pull to refresh

Comments 16

Бегунек не опускается до 0%, если отпустить мышку вне шкалы бегунка, то значение не меняется.

Удивительно, vintage написал комментарий без упоминания mol, а его все равно заминусовали

Ребят, за статьи спасибо. Но убедительная просьба — выработайте единый подход к формированию статей и разбитию их на части. А то как то не понятно — этот объемный материал зашёл одной публикацией, а вот сравнение 5 фрейворков вдруг понадобилось бить на 2 части (https://habr.com/ru/company/ruvds/blog/476288/ и habr.com/ru/company/ruvds/blog/476286)
Собственно как раз после предыдущего разделения решили одним большим куском разделить.
UFO just landed and posted this here
Если я понимаю правильно — теперь надо переписывать все библиотечные компоненты? Может, проще было заоптимизировать конкретное представление, вместо столь далеко идущих изменений во всем приложении. За это я и не люблю фреймворки на скриптовых языках — очень легко, увлекшись какой-то идеей, пропустить момент когда ваша версия уже превратилась в свой собственный фреймворк, не совместимый с исходным.
Reflect.set(target, propertyKey, true)

А чем это отличается от target[propertyKey] = true? Автор этим хотел явно указать на то, что target есть объект сторонний и мутный? Или есть какое-то функциональное отличие?

Сделав target[propertyKey] = true, вы затрёте оригинальное свойство. Из примера:

export class Component {
    @observed() state = {
        name: ''
    };

Здесь target — Component, propertyKey — «state».

В противоположность этому Reflect хранит данные отдельно. Не обязательно использовать для этого Reflect, можно было бы например засунуть Map в скрытое свойство наподобие ctx[subscriptionsSymbol].

Если честно, то я ничего не понял. Правда я на Angular-е ни строки не писал. Не знаю что в @observed внутри находится. Надо будет углубиться.

Вы путаете Reflect.set, что, без 4го аргумента, является эквивалентом простого присваивания свойства, как и писал faiwer, с Reflect.defineMetadata.
из соображений эффективности, пользоваться функцией ɵdetectChanges не стоит
вместо неё рекомендуется использовать функцию ɵmarkDirty.

Проблема в том, что markDirty() помечает "грязной" всю вышестоящую ветку дерева начиная с корня и заканчивая нашим компонентом. Даже если промежуточные компоненты в этой ветке используют OnPush, они все равно будут отрендерены заново.


В то время, как detectChanges() инициирует проверку изменений вниз от нашего компонента. При этом OnPush в нижестоящих компонентах правильно обрабатывается, и такие компоненты не рендерятся лишний раз.


Буду рад, если кто-то сможет пояснить, почему при этом markDirty() является рекомендуемым подходом (а он-таки является, судя по этому комментарию к функции detectChanges())

Никакой завязки на Ivy тут не вижу. Функции markForCheck и detectChanges доступны и в текущем Ангуляре через ChangeDetectorRef.

А текущем Ангуляре ChangeDetectorRef надо внедрять через конструктор компонента. Это не бы не позволило реализовать декоратор @observed — который в приведенной реализации импортирует markDirty напрямую из Ангуляра

а кто мешает сделать @observed(this)?
Правда необходимость всегда инжектить cd напрягает конечно.
Sign up to leave a comment.