SolidJS выигрывает не «магией», а дисциплиной: где не терять реактивность

SolidJS выигрывает не «магией», а дисциплиной: где не терять реактивность

Solid часто берут за “минимум лишней работы”, но на практике его сила ломается там же, где и у всех: в неправильном разбиении состояния. Если всё хранить в одном объекте, а потом дергать его целиком, вы сами убираете главный плюс fine-grained подхода.

Проверьте три вещи:
— состояние хранится максимально близко к месту использования;
— derived-значения считаются через createMemo, а не через ручные пересчёты;
— эффекты createEffect не начинают жить как свалка для бизнес-логики.

Ещё одна типовая ошибка — передавать в компоненты не данные, а “контекст на вырост”. Solid хорошо работает, когда пропсы маленькие и предсказуемые: примитивы, функции-колбэки, узкие объекты. Как только компонент начинает тянуть за собой большой store, рендеры остаются дешёвыми только на бумаге.

И отдельно смотрите на списки. Для длинных коллекций важнее не “перерисовывается ли всё”, а умеете ли вы стабильно обновлять элементы по ключу и не пересоздавать разметку без нужды ⚙️

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