Обновить
2
Алексей Балехов@Balek

Автоматизация и интеграция

1
Подписчики
Отправить сообщение

Я сам предпочитаю обычный импорт из-за простоты, но в данном случае нужно признать, что это может вызвать проблемы. Лучше доставать стор из контекса реакта.


Костылем я назвал puppeter.


Разговор был не о готовой архитектуре, а о том, что мы строим под приложение. Но если хотите пример хорошей архитектуры, где уже решены эти вопросы, посмотрите фреймворк DerbyJS.

Или можно построить нормальную архитектуру без костылей в виде жирного браузера, подставляющего переменные в текстовый шаблон.

Подключение стора через import сделает невозможным SSR.

v => (this.userInfo.name = v)

Без этого не обойтись? Почему-то в последние годы бойлерплейт стал повсеместным.
Не хочется ввязываться в споры про коммунизм, но марксистские идеи пока ещё никто не реализовывал. Маркс предсказывал, что капитализм по мере развития перейдёт в коммунизм. И никаких других способов «строительства» не предлагалось.
Key-prop — это частный случай общей проблемы. Сами по себе шаблоны статичны. Если их описывать декларативно, то можно точно сопоставить, какие изменения данных как именно изменяют DOM. Императивно перевычислять куски шаблона и сравнивать их со старыми кусками не нужно. Поэтому хотелось бы видеть к MobX нормальный View-слой, который не будет отбрасывать информацию об изменениях данных, чтобы потом перебирать Virtual DOM в поисках изменений.
vintage говорит о полном ререндеринге вашего компонента App, когда достаточно заменить innerText у h1. В шаблоне всё написано (будь он декларативным, этой информацией можно было бы пользоваться), mobx может точно сказать, какие именно данные изменились, но реакт не может этой информацией воспользоваться, а может только перевычислять рендер-функцию заново. Так что такой отличной вещи, как MobX очень не хватает нормальный View.
Приведу другой пример для объяснения. Использование key-prop при генерации html в цикле по значениям массива — это жуткий костыль. MobX может дать информацию, как именно изменился массив и из этой информации и декларативного шаблона однозначно понятно, как менять DOM — добавить/удалить куски или поменять что-то местами.
Да уж, за абстрактными словами вы имели ввиду конкретные вещи.) Теперь я вас понял.

Что вас не устраивает в существующих решениях? Даже если брать старый Ангуляр, там были проблемы с Model, но что было не так с View-слоем? Или чем вас не устраивает Svelte?

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

Извините, промахнулся. Ответил ниже.

Посмотрите видео.

Зачем же вы создание 40к вотчеров? Если у вас столько компонентов, то чем это отличается от Реакта, который также будет тормозить?


В чем проблема обеспечить настоящую декларативность шаблонов с помощью джаваскрипта в браузере?

Неистово плюсую. Вдобавок здесь происходит разнесение сильно взаимосвязанных кусков кода по разным местам, что мешает читать код. А ещё с именами нельзя быть сходу уверенным, в скольких местах они могут быть использованы. Т.е. когда просто читаешь код, непонятно, нужно ли дальше держать это имя в голове или можно освободить память.

А почему вы уверены, что выражение в скобках может быть любым кодом? DerbyJS, например, парсит джаваскрипт в скобках как декларативное выражение. Вплодь до того, что count + 1 можно присвоить значение 2 и count станет равным единице

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

ПДД пункт 9.4. Встань в правый ряд и езжай 40.
А вообще о том и речь, что дороги используются неэффективно.

Привязка декларативна, я имел ввиду сам обработчик. Что за "программная логика"?

Информация

В рейтинге
4 916-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность