В современном мире интерфейсов у вас есть большой выбор библиотек / фреймворков Javascript на выбор, но независимо от того, пишете ли вы корпоративные приложения, поддерживаете несколько приложений с некоторой степенью общности или планируете долгий срок хранения для своего приложения, вы следует рассмотреть возможность использования собственной библиотеки компонентов.
«Зачем это мне?», спросите вы?
Поскольку это удалит много беспорядка из вашего приложения, это будет способствовать повторному использованию компонентов (внутри приложения или между приложениями) и позволит заинтересованным сторонам (дизайнерам, продукту, руководству, коллегам) участвовать в процессе (например, продемонстрировав эту библиотеку).
Поддержка отдельной библиотеки компонентов даже способствует принятию более эффективных дизайнерских решений (например, разъединение, SoC), поскольку не позволяет вам использовать ресурсы вашего приложения (стиль, состояние, язык и т. Д.)
Так почему бы не использовать надежную, хорошо известную библиотеку?
Конечно, можно, и большинство библиотек компонентов отлично справляются со своей задачей, но если вы работаете в организации, вам следует учитывать следующие болевые точки:
- Контроль - вы, вероятно, дойдете до точки, когда вам понадобится более детальный контроль над компонентами.
- Лицензия. Существуют тысячи вариантов лицензий, и не все типы подходят для использования в коммерческих продуктах. Вы, наверное, уже знали об этом, но знаете ли вы, что коммерческой компании необходимо рассмотреть и проверить все лицензии для всего дерева зависимостей?
- Гибкость - вы могли подумать, что ускоряете процесс, используя стороннюю библиотеку, но со временем поймете, что тратите много времени, пытаясь взломать ее, чтобы делать то, что вы хотите.
- Размер - большие приложения обычно страдают от снижения производительности, поэтому лучше иметь компонент, который делает именно то, что вы хотите - ни больше, ни меньше.
- Безопасность. Независимо от того, используете ли вы известную или неизвестную библиотеку, вы можете столкнуться с уязвимостями в системе безопасности. В известных библиотеках это может быть связано с тем, что они больше ориентированы на
Это не означает, что вам следует заново изобретать колесо, но большинство общих компонентов очень легко написать. Однако в некоторых ситуациях можно рассмотреть возможность использования стороннего производителя, но убедитесь, что вы обернули его в свой компонент (таким образом, вы сможете заменить библиотеку при необходимости), и вам все равно нужно учитывать болевую точку. выше.
Приведенные выше бюллетени действительны для всех сторонних библиотек (например, вам, вероятно, не нужна библиотека для глубокого клонирования объекта или для получения элемента DOM)
Не позволяйте лисе охранять курятник
Итак, вы решили, что вам нужна библиотека компонентов, и теперь возникает вопрос: «Кто будет отвечать за эту библиотеку»?
В идеале это должен быть кто-то нейтральный, а не кто-то, кто отвечает за другое приложение в организации, просто потому, что существует больший риск того, что дизайн будет смещен в сторону одного варианта использования без учета общей картины.
Вы также должны учитывать, что поддержка библиотеки компонентов - это постоянная задача. Вам нужен кто-то, кто будет активно подходить к улучшениям, рефакторингу и даже переписыванию кода, когда это необходимо.
Если у вас нет никого нейтрального, выберите того, кто с меньшей вероятностью воспользуется своим положением, и убедитесь, что он или она следует рекомендациям по поддержке библиотеки компонентов.
Один принцип, чтобы управлять ими всеми
Даже если вы не собираетесь выпускать эту библиотеку как проект с открытым исходным кодом, считайте ее таковой.
В двух словах это означает:
- общий, общий, общий - если ваши компоненты имеют определенную логику, они, вероятно, должны быть в отдельном месте (*)
- след - должен быть низким с минимальным количеством зависимостей
- независимое управление версиями
- «Связь» между компонентами должна быть сведена к минимуму
- чистота - компоненты должны полагаться исключительно на свои реквизиты
(*) вам следует подумать о поддержке другой библиотеки, которая будет менее строгой (не обязательно должна быть универсальной или сохранять чистоту компонентов) для обработки всех неуниверсальных компонентов / утилит.
Заключение
Отделение общих компонентов от остального кода улучшит ваши дизайнерские решения, особенно если вы будете следовать мышлению библиотеки с открытым исходным кодом, и может иметь большое влияние на вашу организацию.
Если ваша организация еще не поддерживает библиотеку, вам обязательно стоит внести ее в список, а если вы это сделаете, убедитесь, что делаете это правильно. В конечном итоге организация и разработчики получат от этого большую пользу.
