Что вас не устраивает в существующих решениях? Даже если брать старый Ангуляр, там были проблемы с Model, но что было не так с View-слоем? Или чем вас не устраивает Svelte?
Никто и не предлагает решать эту задачу в общем виде. Это нужно было бы только разработчикам реакта, чтобы не перевычислять рендер-функцию полностью. Нормальные люди используют декларативные шаблоны, имеющие разумные ограничения, потому с лёгкостью обновляемые инкрементально.
Неистово плюсую. Вдобавок здесь происходит разнесение сильно взаимосвязанных кусков кода по разным местам, что мешает читать код. А ещё с именами нельзя быть сходу уверенным, в скольких местах они могут быть использованы. Т.е. когда просто читаешь код, непонятно, нужно ли дальше держать это имя в голове или можно освободить память.
А почему вы уверены, что выражение в скобках может быть любым кодом? DerbyJS, например, парсит джаваскрипт в скобках как декларативное выражение. Вплодь до того, что count + 1 можно присвоить значение 2 и count станет равным единице
Типичное движение на московской кольцевой. Пять рядов едущих 80 кмч при разрешенных 100. Протискиваешься вперед — километр пустой дороги, а потом новое стадо. Я называю этот эффект "тупостью".
Я понимаю, что все эффекты, которые описаны в статье и комментариях — естественны, и полностью их решить не получится. Но можно было бы выжать из дорог гораздо больше.
Видимо у нас очень разные определения тупиковости. Потому что мне время (первые минут 30) уже все показало. Например, когда для оптимизации, нужно в shouldComponentUpdate внести то, что и так очевидно из render-функции. Или необходимость указывать key-property при рендере массива. Или перечислять значения вторым аргументом в useCallback. Эти проблемы нужно решать в фундаменте, а не плагинами к бабелю. Тогда будет архитектура, а не набор костылей.
Я говорю о том, что очень много усилий вкладывается в развитие тупиковой идеи Virtual DOM diff. Если бы последние пять лет сообщество вкладывалось в развитие настоящей реактивности, то были бы защиты от дурака. И, скорее всего, они были бы лучше тех, что есть сейчас. Потому что декларативный код даёт больше возможностей для автоматического анализа, оптимизации и т.п.
Полностью согласен со всеми, кто обвинил меня в резкости. Обычно стараюсь сдерживаться. Но в этой теме меня особенно задевает не то, какой Реакт плохой, а общественная слепота. Повторю, что сказал в первом комментарии: архитектурные проблемы Реакта должны быть очевидны любому программисту с самого первого знакомства. Рич их разжёвывает 30 минут, а в комментариях несколько человек продолжают отвечать, что я «без всяких оснований» ругаю Реакт. Почему это происходит?
Так тут же дело в абстрактной идеологии. Грубо говоря, сложность программы на Реакте — O(n), хотя проблема решается за O(1). И это заложено в самой архитектуре.
Я не очень понял, что именно вам не нравится в 40к вотчерах. Проблема Ангуляра была ровно такая же, как и Реакта, только в Model слое, а не View. Ангуляр диффал данные, Реакт — виртуальный DOM. И то, и другое очевидно будет тормозить. Но дифф данных — это более хорошая архитектура. Потому что было несколько способов решить проблемы, оставив тот же подход в View. А Реакт — это шаг назад, потому что рано или поздно его все равно придётся выкинуть и сделать нормальную декларативность.
Смотря в каком смысле "предложить". Как я уже сказал, настоящая декоративность, если я не ошибаюсь, существовала в Knockout и Angular. Можно было развивать эти идеи. Я думаю, что большинство просто повелось на мнимую простоту Реакта. Для первых шагов было проще понять, как он работает. Но конечная задача все равно гораздо более сложная. И в реальном мире Реакт обрастает кучей всего, что делает этот подход таким же сложным, как Ангуляр, но совершенно тупиковым. Вынос рендера в вебворкер для внесения десятка изменений в DOM этому подтверждение.
А ещё я всем рекомендую посмотреть, как устроен View-слой в уже много лет как полумертвом DerbyJS. Например, там нет костыльного key-property. Когда вы изменяете массив в моделе, на уровне шаблона уже понятно, какие изменения нужно внести в DOM. Зачем ещё что-то сопоставлять по ключу? Хорошая программа (в данном случае фреймворк) строится от интерфейса, а не интерфейс подстраивается под то, как программисту удобнее его реализовать. Имитация декларативности через императивщину — это именно второй случай. Заморачиваться с парсингом декларативного языка долго — проще перезапускать функцию рендера. Но в итоге все равно люди обвешались babel-плагинами.
Что вас не устраивает в существующих решениях? Даже если брать старый Ангуляр, там были проблемы с Model, но что было не так с View-слоем? Или чем вас не устраивает Svelte?
Никто и не предлагает решать эту задачу в общем виде. Это нужно было бы только разработчикам реакта, чтобы не перевычислять рендер-функцию полностью. Нормальные люди используют декларативные шаблоны, имеющие разумные ограничения, потому с лёгкостью обновляемые инкрементально.
Извините, промахнулся. Ответил ниже.
Посмотрите видео.
Зачем же вы создание 40к вотчеров? Если у вас столько компонентов, то чем это отличается от Реакта, который также будет тормозить?
В чем проблема обеспечить настоящую декларативность шаблонов с помощью джаваскрипта в браузере?
Неистово плюсую. Вдобавок здесь происходит разнесение сильно взаимосвязанных кусков кода по разным местам, что мешает читать код. А ещё с именами нельзя быть сходу уверенным, в скольких местах они могут быть использованы. Т.е. когда просто читаешь код, непонятно, нужно ли дальше держать это имя в голове или можно освободить память.
А почему вы уверены, что выражение в скобках может быть любым кодом? DerbyJS, например, парсит джаваскрипт в скобках как декларативное выражение. Вплодь до того, что count + 1 можно присвоить значение 2 и count станет равным единице
Не подскажете, в чем там проблема? Приходится явно указывать ангуляру, что данные обновились?
ПДД пункт 9.4. Встань в правый ряд и езжай 40.
А вообще о том и речь, что дороги используются неэффективно.
Привязка декларативна, я имел ввиду сам обработчик. Что за "программная логика"?
Типичное движение на московской кольцевой. Пять рядов едущих 80 кмч при разрешенных 100. Протискиваешься вперед — километр пустой дороги, а потом новое стадо. Я называю этот эффект "тупостью".
Я понимаю, что все эффекты, которые описаны в статье и комментариях — естественны, и полностью их решить не получится. Но можно было бы выжать из дорог гораздо больше.
Поясните, пожалуйста, что тут недекларативного, кроме обработчика события?
Видимо у нас очень разные определения тупиковости. Потому что мне время (первые минут 30) уже все показало. Например, когда для оптимизации, нужно в shouldComponentUpdate внести то, что и так очевидно из render-функции. Или необходимость указывать key-property при рендере массива. Или перечислять значения вторым аргументом в useCallback. Эти проблемы нужно решать в фундаменте, а не плагинами к бабелю. Тогда будет архитектура, а не набор костылей.
Так-то любой декларативный код будет скомпилирован в императивный)
Так тут же дело в абстрактной идеологии. Грубо говоря, сложность программы на Реакте — O(n), хотя проблема решается за O(1). И это заложено в самой архитектуре.
Я не очень понял, что именно вам не нравится в 40к вотчерах. Проблема Ангуляра была ровно такая же, как и Реакта, только в Model слое, а не View. Ангуляр диффал данные, Реакт — виртуальный DOM. И то, и другое очевидно будет тормозить. Но дифф данных — это более хорошая архитектура. Потому что было несколько способов решить проблемы, оставив тот же подход в View. А Реакт — это шаг назад, потому что рано или поздно его все равно придётся выкинуть и сделать нормальную декларативность.
Смотря в каком смысле "предложить". Как я уже сказал, настоящая декоративность, если я не ошибаюсь, существовала в Knockout и Angular. Можно было развивать эти идеи. Я думаю, что большинство просто повелось на мнимую простоту Реакта. Для первых шагов было проще понять, как он работает. Но конечная задача все равно гораздо более сложная. И в реальном мире Реакт обрастает кучей всего, что делает этот подход таким же сложным, как Ангуляр, но совершенно тупиковым. Вынос рендера в вебворкер для внесения десятка изменений в DOM этому подтверждение.
А ещё я всем рекомендую посмотреть, как устроен View-слой в уже много лет как полумертвом DerbyJS. Например, там нет костыльного key-property. Когда вы изменяете массив в моделе, на уровне шаблона уже понятно, какие изменения нужно внести в DOM. Зачем ещё что-то сопоставлять по ключу? Хорошая программа (в данном случае фреймворк) строится от интерфейса, а не интерфейс подстраивается под то, как программисту удобнее его реализовать. Имитация декларативности через императивщину — это именно второй случай. Заморачиваться с парсингом декларативного языка долго — проще перезапускать функцию рендера. Но в итоге все равно люди обвешались babel-плагинами.
Большое спасибо за ссылку.