Привет! Спасибо на добром слове 🙂 Я бы организовал такую ситуацию через общий Observable сервис, объявленный где-то сверху, чтобы у всех необходимых view был до него доступ и через него бы обновлял всё, что надо обновить. Другой вариант — делать у компонентов публичный метод refresh, достукиваться как-то до них и вызывать его. Стоит отметить, что через @View/ContentChild(ren) достучаться сразу до ChangeDetectorRef через read нельзя: https://github.com/angular/angular/issues/34347
Когда кнопки «торчат» наружу — не придётся всё переделывать, если дизайнеры решат добавить к вкладкам иконки или отображать количество непрочитанных сообщений. Связывание компонентов это не плохо, даталист и опции — части одного целого, просто организованы гибко, чтобы у пользователя была свобода отображения.
Да, мы планировали использовать её как «источник истины» для определения международных форматов, когда будем делать полноценное дополнение к Maskito для телефонных номеров.
Вот как раз для того, чтобы такого не было, а было одно централизованное хорошее решение с выделенными ответственными людьми и была создана библиотека, которая упоминается в конце статьи :) Кроме того, она будет в open source и, надеюсь, пригодится не только нам. Но сначала надо её доделать и внедрить.
У нас в Тинькофф принято работать с форматом +XXXXXXXXXX, а выводить отформатированным. Разумеется 8 автозаменяется на +7 и при написании, и при вставке/дропе, и при автофилле. Как и все посторонние символы вроде пробелов и дефисов заменяются на заданный формат.
Красиво отформатированный ввод, если он сделан корректно, создаёт у пользователя ощущение опрятности интерфейса, помогает ему сверить значение (например разделение тысяч пробелом при форматировании суммы), не препятствует вводу и исправляет ошибки (например, если забыл переключить язык и набираешь точку/запятую/ю/б при вводе копеек). То, что это сложно сделать хорошо не повод отказываться от преимуществ, которые это даёт продукту. Наше дело, как фронтендеров, дать пользователю интерфейс, решающий его задачу настолько хорошо, насколько мы можем. Будем стараться!
На странице просто базовый международный пример, который не хотелось усложнять, так как 8/+7 чисто русская тема. Когда выпустим maskito 1.0 и начнём на него переходить, то обязательно всё это учтём :)
С момента написания статьи позиция команды Angular поменялась на то, что markDirty они пока не планируют в публичный API выносить. Можно импортнуть как приватный API в виде ɵmarkDirty.
Сейчас попробовал и всё декодирует, даже если с нескольких пробелов начать. Звук сейчас идёт с нарастанием за 20мс — это контролируется пайпом waAudioParam:
[gain]="morse$ | async | waAudioParam : 0.02"
Примерно так обычно оно и звучит везде, но можно и удлинить наплыв, если кажется, что резковато. Поправил на 50мс в демке.
Директива - один из способов подложить что-то в DI дерево. Да, на примере StackBlitz показано, как можно раскидать в разные места разную реализацию с помощью директив.
Паттерн настроек без кнопки "Сохранить" встречается довольно часто. А написанный тут подход вполне можно переложить на показ нотификашек (тогда не понадобится компонент-обёртка, будет просто директива) и произвольный контрол, к примеру, чекбокс.
Ну и в статье всё именно так, как ты написал во втором абзаце :)
Но ведь если компонент А никак не связан с компонентом Б — почему он должен обновляться? Связь сверху вниз можно осуществить через инпуты и OnPush это подхватит. Связь параллельных вьюх надо осуществлять через сервис. Уж точно не надо строить своё приложение, полагаясь на волшебную связь всего со всем.
OnPush, по сути, что-то меняет только для асинхронных операций. Если они написаны через RxJS, без императивных подписок и ручного изменения внутренних состояний, то OnPush ничего не добавит. Мне комфортно так писать и поддерживать код. RxJS требует особой подстроки мышления. Если её нет, то может возникать много непонимания, фрустрации и неприязни. Тогда с OnPush будет тяжело. Самостоятельно заботиться об обновлении мне не приходится. Практически всегда я не подстраиваюсь под OnPush, а просто пишу так, что при его включении всё будет работать и так. Разбиение интерфейса, если это вдумчивая декомпозиция, приложению только на пользу. В какой-то степени OnPush похож на strict в TypeScript. Можно сказать, что без него проще что-то накидать и не нужен лишний код проверок, но кодовая база с ним становится более предсказуемая, более аккуратная и надёжная. Ну и мигрировать приложение на него, если он сразу не был включен тоже будет довольно трудно 🙂
Иногда в проектах можно встретить очень странный RxJS код, приправленный сайдэффектами, tap`ами и перебрасываниями туда сюда в стор чего-либо, что иногда может сказаться. Я не имел ввиду какой-то термин :)
Мы любим Ангуляр
Привет! Спасибо на добром слове 🙂 Я бы организовал такую ситуацию через общий
Observableсервис, объявленный где-то сверху, чтобы у всех необходимых view был до него доступ и через него бы обновлял всё, что надо обновить. Другой вариант — делать у компонентов публичный методrefresh, достукиваться как-то до них и вызывать его. Стоит отметить, что через@View/ContentChild(ren)достучаться сразу доChangeDetectorRefчерезreadнельзя:https://github.com/angular/angular/issues/34347
Когда кнопки «торчат» наружу — не придётся всё переделывать, если дизайнеры решат добавить к вкладкам иконки или отображать количество непрочитанных сообщений. Связывание компонентов это не плохо, даталист и опции — части одного целого, просто организованы гибко, чтобы у пользователя была свобода отображения.
Да, мы планировали использовать её как «источник истины» для определения международных форматов, когда будем делать полноценное дополнение к Maskito для телефонных номеров.
Вот как раз для того, чтобы такого не было, а было одно централизованное хорошее решение с выделенными ответственными людьми и была создана библиотека, которая упоминается в конце статьи :) Кроме того, она будет в open source и, надеюсь, пригодится не только нам. Но сначала надо её доделать и внедрить.
Верно. Тут уже зависит от продукта, главное, чтобы маска позволяла это технически решить. Посмотрим, что у нас из этого выйдет.
У нас в Тинькофф принято работать с форматом
+XXXXXXXXXX, а выводить отформатированным. Разумеется 8 автозаменяется на +7 и при написании, и при вставке/дропе, и при автофилле. Как и все посторонние символы вроде пробелов и дефисов заменяются на заданный формат.Красиво отформатированный ввод, если он сделан корректно, создаёт у пользователя ощущение опрятности интерфейса, помогает ему сверить значение (например разделение тысяч пробелом при форматировании суммы), не препятствует вводу и исправляет ошибки (например, если забыл переключить язык и набираешь точку/запятую/ю/б при вводе копеек). То, что это сложно сделать хорошо не повод отказываться от преимуществ, которые это даёт продукту. Наше дело, как фронтендеров, дать пользователю интерфейс, решающий его задачу настолько хорошо, насколько мы можем. Будем стараться!
На странице просто базовый международный пример, который не хотелось усложнять, так как 8/+7 чисто русская тема. Когда выпустим maskito 1.0 и начнём на него переходить, то обязательно всё это учтём :)
Спасибо за подсвеченные моменты. К версии 1.0.0 обязательно поправим!
С момента написания статьи позиция команды Angular поменялась на то, что
markDirtyони пока не планируют в публичный API выносить. Можно импортнуть как приватный API в видеɵmarkDirty.Пока точных планов о выходе реакт версии в opensource я назвать не могу.
Там всё на токенах глобальных объектов отсюда:
https://github.com/ng-web-apis/common
Под SSR нужно подключить вот это:
https://github.com/ng-web-apis/universal
Для пользователя всё будет очень прозрачно. Если потребуется добавить нативные атрибуты, то можно будет написать так:
Старый вариант также останется возможен, если ничего навешивать не нужно.
Подобный формат появится в следующем релизе 2.33.0, 7 февраля.
Добавил blur на клик :)
Сейчас попробовал и всё декодирует, даже если с нескольких пробелов начать. Звук сейчас идёт с нарастанием за 20мс — это контролируется пайпом
waAudioParam:Примерно так обычно оно и звучит везде, но можно и удлинить наплыв, если кажется, что резковато. Поправил на 50мс в демке.
Ага, я так и написал в начале второй части 🙂
Директива - один из способов подложить что-то в DI дерево. Да, на примере StackBlitz показано, как можно раскидать в разные места разную реализацию с помощью директив.
Паттерн настроек без кнопки "Сохранить" встречается довольно часто. А написанный тут подход вполне можно переложить на показ нотификашек (тогда не понадобится компонент-обёртка, будет просто директива) и произвольный контрол, к примеру, чекбокс.
Ну и в статье всё именно так, как ты написал во втором абзаце :)
Но ведь если компонент А никак не связан с компонентом Б — почему он должен обновляться? Связь сверху вниз можно осуществить через инпуты и OnPush это подхватит. Связь параллельных вьюх надо осуществлять через сервис. Уж точно не надо строить своё приложение, полагаясь на волшебную связь всего со всем.
OnPush, по сути, что-то меняет только для асинхронных операций. Если они написаны через RxJS, без императивных подписок и ручного изменения внутренних состояний, то OnPush ничего не добавит. Мне комфортно так писать и поддерживать код. RxJS требует особой подстроки мышления. Если её нет, то может возникать много непонимания, фрустрации и неприязни. Тогда с OnPush будет тяжело. Самостоятельно заботиться об обновлении мне не приходится. Практически всегда я не подстраиваюсь под OnPush, а просто пишу так, что при его включении всё будет работать и так. Разбиение интерфейса, если это вдумчивая декомпозиция, приложению только на пользу. В какой-то степени OnPush похож на strict в TypeScript. Можно сказать, что без него проще что-то накидать и не нужен лишний код проверок, но кодовая база с ним становится более предсказуемая, более аккуратная и надёжная. Ну и мигрировать приложение на него, если он сразу не был включен тоже будет довольно трудно 🙂
Иногда в проектах можно встретить очень странный RxJS код, приправленный сайдэффектами, tap`ами и перебрасываниями туда сюда в стор чего-либо, что иногда может сказаться. Я не имел ввиду какой-то термин :)