Просто of, без Observable

вроде пошло, спасибо)

какаие есть идеи?
есть список, по нажатию элемент открывается в компоненте, при нажатии кноки назад,
1: не нужно заного грузить лист
2: вернутся на тот элемент в списке который был открыт

1. Сохранить список в сервисе
2. Вернуться по роуту, в роуте будет айдишкка
3. По айдишке взять елемент со списка

есть какой то стандартный способ scrollTo?

Нет

В SCSS есть Partial. При использовании в компонентах такое не используется?

В последних версиях просто of(data), без Observable

без Observable, заработало спасибо

В компонентах CSS инкапсулируется и становится только для компонента. Есть общие стили в ассетах, там можешь спокойно разбивать на части и работать с ними. Важная особенность компонентных стилей: всё что вставляется через innerHTML, дочерние компоненты или сторонние директивы/модуля не будут применены стили. Можно через ViewIncapsulation.None это поправить, но это крайне нерекомендовано, т.к. они становятся глобальными, и лучше их писать в ассетах тогда

Перефразирую вопрос: кто как решал проблему долгой компиляции юнит тестов?

Привет всем! Ищу решения для кеша данных в приложении для ускорения загрузки приложения. Идея такова, что данные приложения при работе с ним сохраняются в кеше, а при его перезагрузке сначала берутся из кеша, а затем выполняется актуальный запрос, который подтягивает реальные данные, но вот интересуют следующие проблемы:
- хранение кеша. В данный момент в localStorage, но планируется IndexedDB - это оптималный вариант, но работа с ним не самая удобная, особенно если что-то нужно получить синхронно;
- место внедрения кеша. Можно реализовать отдельным сервисом, как HttpClient, что усложнит внедрение, если проект большой. Можно же сделать через Interceptor, что требует более детальной настройки;
- запросы с параметрами. Не все данные есть в кеше, да и запросы могут идти с разными опциями,  нужно по-хорошему их все сортировать, получать хеш и хранить, но тогда проблема со страничными данными, которые могут друг друга частично или полностью перекрывать (например получить первых 30 пользователей, а другим запросом первых 15 пользователей - вторые данные содержатся в первых, но опции запросов разные);
- когда использовать кеш, а когда нет. Например, при запуске приложения нужно точно пользоваться кешем, в то время как во время работы в него нужно только сохранять.

Буду благодарен за хорошие статьи и идеи по данному вопросу.

Нужно избавляться от ненужных зависимостей в тестах. Провайдим по минимуму, только нужное. Меняем карму на джест, оптимизируем.

Насчет "крайне нерекомендовано" я бы не стал горячиться

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

Можно хранить в indexeddb, а после запуска, данные которые хотите получать синхронно, дублировать в локалсторадж. Но нужно будет продумать стратегию разогрева и консистентности такого гибридного кеша

Не вариант в том случае, если данных > 5Мб

Возможно да, иногда имеет место быть в небольших проектах. Но я бы не рекомендовал в больших проектах, если не используется БЭМ, т.к. именования могут повторяться и будут конфликты

Попробуйте джест, возможно окажется быстрее. Создаётся тестовое ложе ака билдится весь проект, отсюда и задержка

Доставать 5 метров из синхронного кеша - не лучшее решение