Сейчас попробовал и всё декодирует, даже если с нескольких пробелов начать. Звук сейчас идёт с нарастанием за 20мс — это контролируется пайпом waAudioParam:
[gain]="morse$ | async | waAudioParam : 0.02"
Примерно так обычно оно и звучит везде, но можно и удлинить наплыв, если кажется, что резковато. Поправил на 50мс в демке.
Директива - один из способов подложить что-то в DI дерево. Да, на примере StackBlitz показано, как можно раскидать в разные места разную реализацию с помощью директив.
Паттерн настроек без кнопки "Сохранить" встречается довольно часто. А написанный тут подход вполне можно переложить на показ нотификашек (тогда не понадобится компонент-обёртка, будет просто директива) и произвольный контрол, к примеру, чекбокс.
Ну и в статье всё именно так, как ты написал во втором абзаце :)
Но ведь если компонент А никак не связан с компонентом Б — почему он должен обновляться? Связь сверху вниз можно осуществить через инпуты и OnPush это подхватит. Связь параллельных вьюх надо осуществлять через сервис. Уж точно не надо строить своё приложение, полагаясь на волшебную связь всего со всем.
OnPush, по сути, что-то меняет только для асинхронных операций. Если они написаны через RxJS, без императивных подписок и ручного изменения внутренних состояний, то OnPush ничего не добавит. Мне комфортно так писать и поддерживать код. RxJS требует особой подстроки мышления. Если её нет, то может возникать много непонимания, фрустрации и неприязни. Тогда с OnPush будет тяжело. Самостоятельно заботиться об обновлении мне не приходится. Практически всегда я не подстраиваюсь под OnPush, а просто пишу так, что при его включении всё будет работать и так. Разбиение интерфейса, если это вдумчивая декомпозиция, приложению только на пользу. В какой-то степени OnPush похож на strict в TypeScript. Можно сказать, что без него проще что-то накидать и не нужен лишний код проверок, но кодовая база с ним становится более предсказуемая, более аккуратная и надёжная. Ну и мигрировать приложение на него, если он сразу не был включен тоже будет довольно трудно ?
Иногда в проектах можно встретить очень странный RxJS код, приправленный сайдэффектами, tap`ами и перебрасываниями туда сюда в стор чего-либо, что иногда может сказаться. Я не имел ввиду какой-то термин :)
События, которые стреляют очень часто, например scroll, mousemove, dragmove могут быть хорошими кандидатами на запуск вне зоны. Но чаще всего это всё же requestAnimationFrame.
У нас в компании используются и React, и Angular. Но почти все статьи, в том числе и про библиотеку компонентов, это был Angular (1389 против 231 местных очков вклада в хаб). Так что не знаю, откуда вы взяли про "все прошлые статьи были про React" :)
console.log прописан в стриме test. Он дёргается 2 раза, потому что мы байндим его на data-test и style.height.px. Так же мы от него создаём стрим active, ведь мы его пайпим. Там ещё 2 подписки — на class._active и disabled. Если test записать вот так, то console.log будет один:
1) Так можно указывать более общий тип, чтобы, если что, подменять реализацию — в первой строчке Observable<void> а не TuiDestroyService. Даже надо бы <unknown> написать :)
2) Раньше без этого нельзя было собирать проект без метаданных, что усложняло работу с Universal
3) Токены без этого не подрубишь, а мне нравится единообразие — поэтому пишу всегда одинаково, не думая, токен там или сервис
Да, там 4 разных байндинга, соответственно, 4 разные подписки. Можно порулить через share, но вообще это довольно экстремальный кейс, когда тебе надо на несколько сущностей забайндить один и тот же стрим :)
Боюсь, что по этому не подскажу. API матириала чрезвычайно раздут и сложен в понимании. Мы не ориентировались на него, когда создавали свою библиотеку. Более того, концепция порталов была заложена у нас почти в неизменном виде с самого начала в 2017 году, когда на дворе был Angular 4 и не было Material CDK, и с тех пор служит нам верой и правдой :)
В первую очередь, оборачивание помогает изолировать контекст наложения. Это очень полезно и часто многие фронтендеры про это не знают и пытаются решить проблему вертикальности z-index`ами. Кроме того, в нашем случае оборачивание помогает позиционировать выпадашки — поскольку так мы можем позицинировать их абсолютно и при глобальном скролле их положение не будет скакать. Ну а в случае хинтов и диалогов без враппера не обойтись, ведь там заложена определённая логика для каждого элемента. Это уже не совсем портал в понимании Material CDK, но портал в более общем понимании, когда какой-то элемент мы показываем не в том месте в DOM, где он определён.
Root ещё подключает наши плагины (подробнее о них тут). Некоторые компоненты на это полагаются, так что лучше root подрубить, всё-таки, хотя бы модуль :)
Имеется ввиду не rtl, а именно выравнивание. По дизайну было задумано такое поведение в табличном представлении, но в будущем добавим возможность задания выравнивания. Так же был запрос от англоязычных пользователей, чтобы знак валюты можно было ставить до суммы. Если у вас есть ещё какие-то конкретные предложения и замечания — забегайте в наш гитхаб :)
Спасибо. Интересное решение. Пока не встречал у себя необходимости чистки кэша. С ходу, вроде как, идёт в разрез с моим представлением об использовании подобных методов. Я бы это сделал через протухающий стрим, всё-таки.
Сейчас попробовал и всё декодирует, даже если с нескольких пробелов начать. Звук сейчас идёт с нарастанием за 20мс — это контролируется пайпом
waAudioParam:Примерно так обычно оно и звучит везде, но можно и удлинить наплыв, если кажется, что резковато. Поправил на 50мс в демке.
Ага, я так и написал в начале второй части ?
Директива - один из способов подложить что-то в DI дерево. Да, на примере StackBlitz показано, как можно раскидать в разные места разную реализацию с помощью директив.
Паттерн настроек без кнопки "Сохранить" встречается довольно часто. А написанный тут подход вполне можно переложить на показ нотификашек (тогда не понадобится компонент-обёртка, будет просто директива) и произвольный контрол, к примеру, чекбокс.
Ну и в статье всё именно так, как ты написал во втором абзаце :)
Но ведь если компонент А никак не связан с компонентом Б — почему он должен обновляться? Связь сверху вниз можно осуществить через инпуты и OnPush это подхватит. Связь параллельных вьюх надо осуществлять через сервис. Уж точно не надо строить своё приложение, полагаясь на волшебную связь всего со всем.
OnPush, по сути, что-то меняет только для асинхронных операций. Если они написаны через RxJS, без императивных подписок и ручного изменения внутренних состояний, то OnPush ничего не добавит. Мне комфортно так писать и поддерживать код. RxJS требует особой подстроки мышления. Если её нет, то может возникать много непонимания, фрустрации и неприязни. Тогда с OnPush будет тяжело. Самостоятельно заботиться об обновлении мне не приходится. Практически всегда я не подстраиваюсь под OnPush, а просто пишу так, что при его включении всё будет работать и так. Разбиение интерфейса, если это вдумчивая декомпозиция, приложению только на пользу. В какой-то степени OnPush похож на strict в TypeScript. Можно сказать, что без него проще что-то накидать и не нужен лишний код проверок, но кодовая база с ним становится более предсказуемая, более аккуратная и надёжная. Ну и мигрировать приложение на него, если он сразу не был включен тоже будет довольно трудно ?
Иногда в проектах можно встретить очень странный RxJS код, приправленный сайдэффектами, tap`ами и перебрасываниями туда сюда в стор чего-либо, что иногда может сказаться. Я не имел ввиду какой-то термин :)
События, которые стреляют очень часто, например scroll, mousemove, dragmove могут быть хорошими кандидатами на запуск вне зоны. Но чаще всего это всё же requestAnimationFrame.
У нас в компании используются и React, и Angular. Но почти все статьи, в том числе и про библиотеку компонентов, это был Angular (1389 против 231 местных очков вклада в хаб). Так что не знаю, откуда вы взяли про "все прошлые статьи были про React" :)
Спасибо, поправил!
strictInputTypes отключит везде, а не точечно :)
Не, deprecated конкретная перегрузка, на которую он по ошибке проваливается, если писать
startWith(null).console.logпрописан в стримеtest. Он дёргается 2 раза, потому что мы байндим его наdata-testиstyle.height.px. Так же мы от него создаём стримactive, ведь мы его пайпим. Там ещё 2 подписки — наclass._activeиdisabled. Еслиtestзаписать вот так, тоconsole.logбудет один:Проблем тут будет не больше, чем при любом другом использовании RxJS :)
1) Так можно указывать более общий тип, чтобы, если что, подменять реализацию — в первой строчке
Observable<void>а неTuiDestroyService. Даже надо бы<unknown>написать :)2) Раньше без этого нельзя было собирать проект без метаданных, что усложняло работу с Universal
3) Токены без этого не подрубишь, а мне нравится единообразие — поэтому пишу всегда одинаково, не думая, токен там или сервис
Да, там 4 разных байндинга, соответственно, 4 разные подписки. Можно порулить через
share, но вообще это довольно экстремальный кейс, когда тебе надо на несколько сущностей забайндить один и тот же стрим :)Боюсь, что по этому не подскажу. API матириала чрезвычайно раздут и сложен в понимании. Мы не ориентировались на него, когда создавали свою библиотеку. Более того, концепция порталов была заложена у нас почти в неизменном виде с самого начала в 2017 году, когда на дворе был Angular 4 и не было Material CDK, и с тех пор служит нам верой и правдой :)
В первую очередь, оборачивание помогает изолировать контекст наложения. Это очень полезно и часто многие фронтендеры про это не знают и пытаются решить проблему вертикальности z-index`ами. Кроме того, в нашем случае оборачивание помогает позиционировать выпадашки — поскольку так мы можем позицинировать их абсолютно и при глобальном скролле их положение не будет скакать. Ну а в случае хинтов и диалогов без враппера не обойтись, ведь там заложена определённая логика для каждого элемента. Это уже не совсем портал в понимании Material CDK, но портал в более общем понимании, когда какой-то элемент мы показываем не в том месте в DOM, где он определён.
Root ещё подключает наши плагины (подробнее о них тут). Некоторые компоненты на это полагаются, так что лучше root подрубить, всё-таки, хотя бы модуль :)
Имеется ввиду не rtl, а именно выравнивание. По дизайну было задумано такое поведение в табличном представлении, но в будущем добавим возможность задания выравнивания. Так же был запрос от англоязычных пользователей, чтобы знак валюты можно было ставить до суммы. Если у вас есть ещё какие-то конкретные предложения и замечания — забегайте в наш гитхаб :)
Спасибо. Интересное решение. Пока не встречал у себя необходимости чистки кэша. С ходу, вроде как, идёт в разрез с моим представлением об использовании подобных методов. Я бы это сделал через протухающий стрим, всё-таки.