Обновить

Комментарии 14

Solid прикольный, но у него есть огромный минус по сравнению с реактом. И этот минус — отсутствие экосистемы. Банально ui kit под solid не найти(да, можно использовать чисто css киты, или ненавистный tailwind, но это немного не то)

Пока не будет нормально работающих UI kit components не будет и солида

Для меня наоборот React интуитивнее, потому что в нём по сути нет компиляторной магии (не считая JSX). В Solid больше магии из-за сигналов и иногда без опыта трудно понять, как именно поведёт себя код.

А какая в Solid компиляторная магия? Не путаете со Svelte?

Это ещё $mol не щупали

В реакте компонент не перерендеривается когда пропсы меняются.

В React компонент перерендеривантся всегда если обновляется его родитель в не зависимости от того поменялись ли передаваемые ему пропсы или нет. Чтобы убрать лишнее рендеры нужно явно использовать memo или PureComponent.

Как раз таки наоборот, реакт компоненты перерендериваются почти на каждый чих.
Конечно если оборачивать компоненты в observer из MobX или memo из React то такого не будет

8 лет и удивился реактивности, что он там 8 лет делал

К сожалению я не знаком с Solid.js но хочу сказать пару слов в пользу React. Эта система внесла очень существенное улучшение концепции MVC. Классическая схема предполагает, что модель передает изменения данных в представление и тем самым полностью нарушает принцип независимости компонент. В React представление автоматически отслеживает изменение состояний данных модели при помощи механизма событий и обновляет UI. Аналогично контроллер React следит за событиями UI и представлению нет дела до обработки действий пользователя. Это намного более строго обеспечивает независимость и позволяет разработчику модели полостью абстрагироваться от представлений. Если Solid.js реализует подобный механизм, то это здорово, если нет, то я пока голосую за React.

Реактивное представление было ещё в Knockout.js

Я месяц работаю с Solid

Месяца недостаточно, чтобы наступить на достаточное количество граблей. Примеры в статье детские. Может, с Solid и впрямь очень приятно работать, но после такой статьи не появляется желание попробовать.

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

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

А по сути процитированного: между Сциллой, когда вы добавите функциональность и забудете явно вызвать ререндер какого-то компонента, и Харибдой, когда у вас UI всегда будет актуальный, но JS немножко поработает под капотом, вы выберете второе. К чему все эти страхи: о ужас, компонент перерисовывается? Это не означает патча DOM, да в большинстве случаев не означает видимой просадки в перформансе. До Fiber да, бывало дело.

Вы когда-нибудь работали с иконками в проекте?

SVGR, если нужна динамическая работа с пропсами. Если не нужна, просто импорт svg в компонент средствами сборщика и использование в img или background. Зачем svg class или className, загадка. Ну в самом крайнем случае повесьте на обертку.

А если вы пробуете до React 19 — удачи!

Если конкретный кейс автора решает установка кастомной библиотеки, то это хорошо. Если обновление фреймворка — это плохо.

Библиотека по своей сути прекрасная. Но в прод я-бы её не потащил. Причины две:

  1. Как тут уже писали, экосистема совершенно неразвитая, и за несколько лет, что я за ней слежу, сильных подвижек в этом, увы, совсем не видно.

  2. Она так и не получила поддержку никого из «сильных мира сего». В отличии от «большой тройки», главным её двигателем является всего один человек – Райан Карниато. Есть ещё пара-тройка мейнтейнеров и небольшое сообщество. Как думаете, что случится с продуктом, когда Райану надоест?

    Так, что, для пет-проектов очень даже неплохо, а вот внедрять это на работе – абсолютно дурацкая идея.

Пусть автора и жёстко отчитали, но есть за что. Но я думаю суть в том что конкуренты есть и они пытаются.

Например как этот Reactive UI Rendering - @denshya/proton

github.com/denshya/proton

Можно сказать это наш ответ Реакту) У него тоже есть эти проблемы, но проблемы с экосистемой должны быть решены тем что можно использовать любые библиотеки, не обязательно писать именно под Proton, ну и есть планы сделать React адаптеры для поддержки перехода и когда будут добавлены вне обязательные фичи, у нас в планах сделать UI kit.

Так что если это интересно, могли мне тоже накидать фидбека как и автору, было бы круто)))

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации