Comments 8
Вчера я читал про кастомные хуки в React и там таки тоже был ненавязчивый PR либы reactuse. Сегодня продолжение цикла?
Если вам кажется что простые вещи должны быть проще в реализации, то вы не одиноки. “Simple things should be simple, complex things should be possible” - Alan Kay.
React из-за своей модели абстракции делает простые вещи сложными, а сложные еще сложнее либо не возможными.
Поэтому предлагаю посмотреть на крошечную альтернативу React, где изначально сделано разделение ответственности между State и Render, и разработка идет практически на Vanilla JavaScript.
А что мы должны увидеть?
А что мы должны увидеть?
<div>Since mounted {N} seconds elapsed</div>А в этой демке можно живьем посмотреть.
Нет же, я не понял о каком разделении ответственности в данном примере вы говорите? Какое преимущество над реакт мы должны увидеть?
Кстати, если я правильно понял, что вы подразумеваете под "разделением State и Render", то тут уже нет такого разделения:
import {getElement} from '@fusorjs/dom';
// This function runs once on creation, generating a DOM element
// and its updater function. On update, only its dynamic values
// are diffed and its DOM node is updated.
const ClickCounter = ({count = 0}) => (
<button click_e_update={() => count++}>Clicked {() => count} times</button>
);
const App = () => (
<div>
<ClickCounter />
<ClickCounter count={22} />
<ClickCounter count={333} />
</div>
);
document.body.append(getElement(<App />));И напрашивается вопрос, какие вещи в реакте сделаны сложными, а тут наоборот сделаны проще? Даже беглое знакомство с местным "шаблонизатором" позволяет предположить, что часть нагрузки, которую реакт берет на себя тут приходится прописывать самому. В частности я имею в виду указание на обновление компонента при обновлении данных и связь шаблона с данными. Тут такие базовые вещи приходится прописывать самому. По моему, проще не стало.
Нет же, я не понял о каком разделении ответственности в данном примере вы говорите?
Изменение стейта и рендер в Реакте объединены.
Какое преимущество над реакт мы должны увидеть?
Стейт менеджмент на ваш выбор, можно даже обычные переменные использовать как в примерах. Тонкое управление созданием и обновлением компонентов, стейт менеджментом, диффингом.
В Реакт функциональные компоненты пересоздают внутри себя все данные, отсюда имеем "хуки": useState, useCallback, useMemo, useEffect, useRef... Во Fusor это все не нужно, вам только понадобится одна функция update.
то тут уже нет такого разделения?
Есть разделение. Используйте click_e вместо click_e_update, управление в ваших руках. Посмотрите три версии реализации ClickCounter для лучшего понимания.
ПС: сложность кода библиотеки и клиентского кода на порядок проще и менее многословно.
Изменение стейта и рендер в Реакте объединены.
Значит я верно понял.
В Реакт функциональные компоненты пересоздают внутри себя все данные, отсюда имеем "хуки": useState, useCallback, useMemo, useEffect, useRef... Во Fusor это все не нужно, вам только понадобится одна функция update.
Получается нужно идти дальше в объяснениях. Реакт создает виртуальный дом, поэтому, просто для примера, когда вы работаете со списками, элементы которых прикрыты memo, DOM будет обновляться только для конкретных элементов. Если я правильно понял, во Fusor вам все это придется контролировать ручками или обновлять вообще все элементы списка всегда.
Если вы работаете с компонентом включающим н-компонент делящих одни данные опять придется заниматься микро менеджментом по обновлению только нужных компонентов, или обновлять все.
Поэтому: "Тонкое управление созданием и обновлением компонентов, стейт менеджментом, диффингом. " - оно не тонкое, оно полностью ложится на плечи разработчиков.
Вы говорили:
React из-за своей модели абстракции делает простые вещи сложными, а сложные еще сложнее либо не возможными.
Но на вид все выглядит как раз наоборот, простые вещи для реакта во Fusor уже не такие простые.
ПС: сложность кода библиотеки и клиентского кода на порядок проще и менее многословно.
А куда денется сложность в клиентском коде? Если нагрузка по контролю изменений полностью перекладывается на плечи разработчика уже это само по себе делает клиентский код сложнее, а местами сильно сложнее и точно многословнее.
Я это все к тому, что даже при поверхностном знакомстве Fusor как то особенно не впечатляет после реакта и вью. Есть свои особенности, но ничего качественно нового. Сравнивая с каким-нибудь древнющим Backbone я бы ему отдал предпочтение, но само по себе перекладывание полностью контроля изменений на разработчика, на мой взгляд, не является каким-то существенным плюсом.
Если вы хотите автоматически обновлять ДОМ, то вы можете использовать например Signals. Также вы можете настроить, запустить Diff по всему приложению (как в Реакт), или локально только по нужным помпонентам. Также вы вольны создавать и обновлять ДОМ асинхронно и гранулярно чтобы не затормаживать интерфейс. То что появилось только в Реакт 18-19. И вам для этого не нужно знать новое АПИ (которое тоже не бесплатно на ресурсы). Вам нужно лишь знание JavaScript и универсальных програмистких знаний. Любая функция мемоизации, любой класс Observable, async/await, generators.
Посмотрите как используется Observable pattern для подключения роутинга и автоматического обновления нужных компонентов в real-world примерах. Кстати весь роутинг выплнен в 3 строчки JavaScript. Почему-то люди привыкли считать нормальным чтобы подключать килотонны библиотек для того что делается в 3 строчки кода (react-router).
ПС: вы также в ручную вызываете update/render в Реакт, вызовом функции setState(x) как и во Фьюзоре
Глубокое Погружение в Работу с Таймерами в React