Угловой и передача данных между компонентами: варианты использования Resolve Guard и внедрение сервисов

Question

В Angular существует несколько способов передачи данных в компонент, в частности, можно использовать Resolve guard для загрузки данных еще до создания компонента, чтобы он всегда был доступен, или можно ввести службу в конструктор компонента и подписаться на его data$ stream и начать с нуля или, возможно, по умолчанию, ожидая загрузки фактических данных.

Я не могу понять, когда один подход может быть предпочтительнее или более подходящим для использования по сравнению с другим, онлайн-примеры - это просто не показывать пользователю пустой интерфейс. Но разработчики могут создать интерфейс-заполнитель (скелет / фантом) при загрузке данных, и это действительно может быть лучше для пользователя, так в чем смысл? Пользовательский интерфейс не будет заблокирован для пользователя.

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

Answer 1

Лучший подход к передаче данных компонентам с использованием поставщиков DI . Это мой личный выбор, но я постараюсь описать его в 1-м пункте. Этот подход подходит для средних и крупных приложений.

Почему?

1. Это не зависит от поставщика данных . Вы можете легко изменить поставщиков данных или преобразование данных в своем провайдере и внедрить этого провайдера в компонент. Очень популярный случай, когда мы используем route.snapshotвнутри компонента и получить от него данные. Это делает ваш компонент зависимым от маршрута, и если вы переместите этот компонент в другую часть приложения, он не будет работать. Но если вы поместите всю логику получения данных в провайдеры, это сделает ваш компонент более гибким. Всегда думайте о том, «могу ли я легко повторно использовать свой компонент в другой части приложения», и после этого вы поймете «идею поставщиков».
2. Мы можем легко сменить поставщика, если нам нужно перейти к другому поставщику данных, но это не повлияет на наши компоненты.
3. У нашего компонента меньше строк кода .
4. Легко тестировать компоненты и провайдеры.

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

Если ваше приложение является средним и большим, лучше всего использовать частных поставщиков DI.

Этот ответ был вдохновлен одним классным постом от Indepth.dev .