Упрощаем универсальное/изоморфное приложение на React + Router + Redux + Express

[pawlo16]

Что можно улучшить

Очевидно, Typescript добавить в первую очередь

[frux]

не надо называть очевидными решениями вечные темы для холиваров

[dfuse]

С моей стороны поддержка TS будет заключаться в удалении этой строки, потому как остальное зависит сугубо от конфигурации Babel и Webpack, а это вне ответственности библиотеки.

[noneim]

Получается такая схема — есть jsx компонент, который сначала отрендерен статически в html код на странице (серверный рендеринг). Потом на этой же странице загружаются js скрипты, которые затирают исходный html код компонента и создают такое же, но своё dom дерево, связанное с virtualdom.
Но в такой схеме virtual dom кажется лишним. Есть библиотека diffHTML, судя по тестам он нанамного отстает от virtualDOM. Т.е. в идеале хотелось бы, когда js код загрузится на странице — он сравнивал существующее дерево в html коде страницы и код, полученный от JSX, и менял только отличающиеся части dom (изменившиеся аттрибуты, добавленные/удаленные узлы и т.п.).
Поясню для чего это нужно: на данный момент, если изменить dom дерево react компонента вручную (через jquery или отладочную панель браузера), то этот компонент будет отображаться некорректно, т.к. направление идет от virtualDOM к реальному DOM, а виртуальный DOM не был изменен и приложение думает что всё ок. При сравнении же реального дом и jsx+данные такого не будет — компонент в любом случае будет приведен к надлежащему виду.

[dfuse]

При клиентском рендеринге серверный HTML не затирается, а используется как каркас, затрется он только если контрольная сумма не сойдется (React проводит проверку на соответствие). Важна именно связка «серверный HTML + данные», потому как именно она обеспечивает работоспособность.

Никто в здравом уме не меняет DOM напрямую через jQuery или отладку. React сам прекрасно справляется с мутациями DOM. А для отладки есть Hot Reload, позволяющий сам код менять и видеть изменения сразу.

[noneim]

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

[comerc]

POC, для понимания потребностей сгодится, но рассматривать серьезно не подходит. А хочется получить production-ready решение в виде подобной самостоятельной библиотеки, не прибитой насмерть к конкретному фреймворку.

[dfuse]

У меня это в продакшене работает. И да, это решение под конкретные составные части, но что в них плохого, если они у всех? Могу добавить поддержку Koa, но Redux и Router то в каждом проекте почти. Хотите совсем production ready — обратите внимание на Next.JS и Electrode от Walmart Labs, подробности тут.

[comerc]

У меня это в продакшене работает.

Выбирая очередную библиотеку, смотрю на все доступные метрики GitHub-а. Хочется обкатанное решение с историей, с кучей выявленных косяков, звездочками, и контрибьютерами.

[BoryaMogila]

Кто ж будет обкатывать, если все будут ждать

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

[comerc]

Пока попробую подружиться с Electrod-ом, а вы как хотите :)

[dfuse]

Именно ))) все проекты с чего-то начинают.

[comerc]

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

[dfuse]

Ну не хотите — не берите, Вас вроде не заставляют. Есть же альтернативы.

[comerc]

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

Ещё раз спасибо за наводку на Electore, пока вообще всё нравится!

Про hapi.js пытаюсь понять, какие есть преимущества перед Express.

[comerc]

Веселые картинки

[dfuse]

Никаких нет преимуществ. Он ужасен.

[comerc]

А почему? Поделитесь опытом, пожалуйста. Я пока вижу, что нужно больше лишних слов, чтобы описать роутинг. Предполагаю, что к нему будет меньше сторонних middleware, но все необходимое должен был исполнить WalmartLab. Замеры производительности смущают, но это еще надо проверять. Пугают обещания, что все есть в одной коробке. На монолиты после Meteor-а аллергия.

[dfuse]

Слабо распространен, миддлвары не поддерживает, производительность плохая, плюсов как-то не видно. Я как-то к Hapi прикручивал Webpack Dev Server, в итоге просто забил после двух дней беспросветных поисков и прикрутил через proxy, т.е. стало два сервера на разных портах. Но это давно было, сейчас может быть проще уже.

[comerc]

Ну не хотите — не берите, Вас вроде не заставляют. Есть же альтернативы.

Хочу остаться вместе с Create React App, отсюда напрашивается вывод — "надо брать"! :)

[BoryaMogila]

Былобы не плохо добавить поддержку для Koa (в особенности для 2.0)

[dfuse]

Это ж Open Source, создайте issue на Гитхабе, в идеале — зашлите пулл реквест :)