Общий угловой компонент для многих случаев использования

Question

Я настраиваю крупный интерфейсный проект для разработки с Angular CLI.Этот интерфейсный проект будет опираться на очень большое количество Rest API, разработанного с использованием фреймворка Php Laravel.Эти API идентичны на 90%, с перечислением, созданием, изменением, удалением (...) сущностей.

Используя библиотеку таких компонентов, как PrimeNG, я действительно надеюсь сэкономить время на разработку моегокомпоненты и реализация проекта в целом.Тем не менее, я новый разработчик Angular, и я не уверен, что знаю все передовые практики, даже после просмотра ряда документов и запуска прототипа.

Моя цель - не иметь угловой компонентдля каждого Rest API.Например, все API, которые возвращают листинг, должны быть доступны через один компонент PrimeNg Generic TurboTable, верно?Этот компонент, конечно, будет настраиваться в зависимости от контекста использования и текущего экземпляра.Например, у меня может быть несколько экземпляров этого genericComponent для отображения списка заказов, списка продуктов, списка (...).

Вместо создания одного компонента на объекты, один для списка продуктов, один для списка заказов (...).

Что вы думаете?Есть ли у вас какие-либо предложения или разъяснения, чтобы помочь мне, пожалуйста?

С уважением, Себастьян

Answer 1

Из своего опыта я хотел бы поделиться некоторыми соображениями. И это мой личный опыт.

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

Сама таблица представляет собой очень сложную вещь, когда она будет иметь несколько функций, таких как разбиение на страницы, сортировка, фильтрация, расширение выбора строк и т. Д. Теперь предположим, что вы используете один компонент таблицы в 3-4 местах. И все они имеют разные заголовки, серверные фильтры, сортировку, а некоторые не имеют никакой функции.

Таким образом, в этом сценарии, в зависимости от типа таблицы Ex: product table or order table, вам придется динамически обрабатывать заголовки, серверные фильтры и все вышеперечисленное во время инициализации компонента. В конце вы закончите использование if else или switch случаев для получения конфигурации таблицы и значения заголовков. А в шаблоне вы будете использовать *ngIf для отображения правильных значений в таблице на основе типа таблицы.

Также вы должны обработать События @Output и @Input. Так что теперь это становится все более и более сложным.

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

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