Thread by @jsunderhood

Давайте наконец перейдем к тому, как разрабатывать микро-библиотеки.

Если вы нашли какую-то проблему или сферу для которой вы можете создать новое lightweight-решение, то не рекомендую сразу писать код, — начните с формирования целей и ограничений.

👇

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

Перед разработкой react-colorful я поставил себе цель сделать импорт своего компонента минимум в 10 раз легче, чем у react-color.

Почему это важно?

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

Во-вторых, для того, чтобы успешно продвигать библиотеку (об этом мы еще поговорим), вам понадобятся объективные преимущества на фоне "конкурентов". И, согласитесь, "10 times lighter than X" будет выглядеть очень хорошо.

К слову, ограничения могут касаться не только размера, но и производительности.

У меня есть один проект — генератор запоминающихся паролей весом в 300 байт. Его цель быть не только легче, но и быстрее своих аналогов.

github.com/omgovich/omgop…

Для этого я "загнал" все популярные генераторы паролей в один бенчмарк, посмотрел на цифры и решил, что мой должен быть в 2 раза быстрее и легче любого из существующих. Этот бенчмарк потом помогал отслеживать как обновление кода влияет на производительность.

Как только вы определили ограничения, настраивайте инструменты для их мониторинга: например, size-limit и benchmark.js. Во время разработки периодически запускайте их, чтобы понять как ваши изменения влияют на размер и скорость работы.

Кроме того, если вы планируете разрабатывать легкий аналог какой-то тяжелой библиотеки, то вам еще до начала разработки стоит подумать хотите ли вы делать похожее/совместимое API.

С одной стороны если API будет таким же, то разработчики легко смогут мигрировать на вашу библиотеку, а с другой — это может привести к тому, что вы повторите неудачную архитектуру. Правильного ответа тут нет, но зачастую, самый оптимальный вариант находится где-то посередине.

Например wouter повторяет знакомые по react-router интерфейсы, но при этом упрощает или отбрасывает advanced-кейсы, которые редко нужны. В большинстве случаев, миграция на эту библиотеку пройдет без проблем.

github.com/molefrog/wouter