Комментарии 25
А как понимать «изоморфное приложение»? Какой-то слишком запутанный термин.
Это такое гибридное (хотя это не совсем правильный термин) приложение, которое использует один и тот же код для рендеринга на клиенте (в данном случае в браузере) и на сервере. Это позволяет не дублировать логику и шаблоны, как в случае с обычными приложениями. Это можно проиллюстрировать такой картинкой:
Картинка
image
НЛО прилетело и опубликовало эту надпись здесь
Этот пример заработал, а в статье нет — ошибки какие-то. Интересно, зачем такие длинные названия аттрибутов «reactid» — изоморфные приложения должны беречь каждый передаваемый байт)
НЛО прилетело и опубликовало эту надпись здесь
Подскажите, можно ли как-то ускорить webpack в вашей демо? У меня на Atom машинке оно собирается больше трёх минут. Кеширование почему-то вообще не попадает. webpack --profile --json показывает гору «причин», но у меня опыта работы с NodeJS мало, а с webpack вообще нет.

Мы с друзьями собираемся попробовать JS для нового проекта, сейчас мы живём на Python (в большей степени на Django замученной до Flask) и по большому счёту нам всё нравится кроме случаев, когда проект развивается в сторону клиентской части (JS).
Отсюда есть желание найти «идеальный инструмент в мире JS» и оставить Python для background задач.

На первый взгляд мне понравилось ваше Demo, но чтобы не было мучительно больно потом, я бы хотел задать несколько вопросов сейчас:
1. Практичен ли описанный вами набор компонент для строительства большого проекта?
2. Какие подводные камни вы знаете/подозреваете?
3. Какие-нибудь комментарии относительно производительности babel, NodeJS и других причастных?
4. Может вы встречали другие серебрянные пули? :) (Например, у меня вот просто несваримость с Vanilla JS и если бы не ES6/ES7, я бы не рискнул нырять в этот мир JS)
По поводу webpack'а не подскажу. Решение специально пока что не искал. По поводу вопросов:

1. большой проект у меня пока что только пишется, но уже могу сказать, что некоторые части лучше выносить в отдельные модули или хотя бы папки (отделить, например блог, галлерею и т.п., от остального сайта).
2. из подводных камней, некоторые неожиданные проблемы с async/await, но о них я написал в статье (про заверните в try-catch иначе не увидите ошибок). Также недавно столкнулся с проблемой интернационализации приложения с помощью react-intl. Всё в целом хорошо, но хранение переводов — небольшая боль. Нет дефолтных переводов, надо везде таскать все переводы для текущего состояния иначе ловим исключения. А ещё нужно приучить себя всегда закрывать теги: <MyComponent /> — работает, <MyComponent></MyComponent> — тоже работает, <MyComponent> (не закрыл) — не скомпилится. И ещё одно, вы могли заметить, что при рендеринге на сервере делается запрос к API, и после рендеринга и запуска скриптов на клиенте делается снова такой же запрос. Я сейчас работаю над устранением этого досадного бага. По итогам намерен написать статью. Вы можете погуглить решения по словам rehydrate/dehydrate (так называлось это в fluxible) или же serialize/unserialize. Автор flummox уже вроде как запилил фикс, Но я ещё не смотрел.
3. babel просто транслирует ES6/ES7 → ES5, он не выполняет код сам. Node.JS шустрая, основной затык обычно в запросах к БД. А вот с React на сервере уже не всё так хорошо. Синтетические тесты (ab -c 5 -t 10 ...) TODO списка на моём i7 с 8GiB памяти показали всего лишь около 200RPS, что не очень плохо, если сравнивать с каким-нибудь PHP. Но довольно медленно, если сравнить с другими шаблонизаторами на Node.JS. И при увеличении количества компонентов, которые рендерятся для текущего состояния, производительность продолжает падать. Этого можно избежать в некоторых случаях, если использовать некоторые оптимизации.
4. серебрянной пули не существует :) Уже давно существуют всякие Meteor'ы, Derby.JS и т.д. Но это полноценные фреймворки и иногда с ними нужно бороться, чтобы сделать что-то нестандартное (сам не работал, но знающие люди так говорят).

Желаю удачи в вашем проекте :)
И это снова я.

Знаете ли вы об Este.js? Он очень напоминает вашу солянку. А про Catberry? Он не использует React и Babel, но тем не менее интересен реализацией progressive rendering и изоморфен.

На счёт benchmark'ов: github.com/catberry/catberry/issues/168

Меня просто интересует ваше мнение, так как я всё никак не остановлюсь с выбором (просто куча других задач и этот JS у меня не в приоритете пока)
Каким-то чудом Este.JS обошел меня стороной. Выглядит очень интересным, спасибо, обязательно утащу оттуда какие-нибудь решения. Насчёт него пока ничего не могу сказать, т.к. внутрь особо не смотрел. Но интересно, как они победили синглтоны и прочие грабли.
На Catberry смотрел несколько месяцев назад, но тогда мне не понравилось, что нужно компоненты держать в catberry_* каталогах, меня крайне раздражают вендор-префиксы. Ещё хотелось для шаблонизации использовать именно React, т.к. он чисто внешне близок к HTML — опять же, на мой вкус.
Ещё, я раньше не сталкивался с термином progressive rendering в данном контексте, можете немного пояснить его?

P.S. Думаю, по поводу Catberry pragmadash лучше может ответить.
С автором Catberry, pragmadash, я пообщался на github, куда я дал ссылку. Но очевидно, что любому автору «своё родное» ближе и понятнее, поэтому я и изучаю взгляды со стороны. :)

Пока что React меня привлекает больше по одной простой причине — за ним стоит Facebook и уже достаточно немалое сообщество, а я в JS мир серверной разработки только сейчас окунаюсь, да и клиентский JS у меня был достаточно костылеобразный (дикие смеси VanillaJS, jQuery и AngularJS...). Кроме того, вслед за ReactJS вполне логичное продолжение изучения идёт в React Native (вот не сложилось у меня с Java для нативной разработки под Android, да и яблочных девайсов у меня больше нет тоже).

Честно говоря, у меня уже мозг пухнет от всего этого разнообразия в JS… Сейчас пытаюсь понять как сдружить Este.JS с реальным миром, где нужна авторизация в API, ну и, собственно, API сервер не пойму на чём писать… С одной стороны раз уже за JS взялся, то логично на нём и API сервер делать, но уж больно сильный соблазн спокойно жить на Python и не мучать себя, хотя и на Python фреймворков для API сервера уже понаписали не один и не два, но всё же меньше, чем на JS :)

Если у вас появятся какие-то комментарии к моему потоку мыслей — я буду очень благодарен.
API можно/нужно писать на том, что удобнее. Главное — HTTP интерфейс для клиента. У себя в pet-project я решил разделить renderer-app и API на кучку модных нынче микросервисов, которые общаются между собой и клиентом по HTTP.
Мои мысли относительно API на JS основаны на том, что поддерживать один язык для проекта проще, чем два (я не говорю о себе, ведь на Python у меня уже большой опыт, а JS мне придётся подтянуть при разработке клиентской части).

Какие языки/фреймворки/библиотеки вы используете для API сервера?
Из того, что я нашёл, я пытался выбрать между Loopback и SailsJS, но поглядываю на Restify просто из-за того, что он очевидным образом самый гибкий (но в этом же и его слабость — слишком много нужно писать самому). Express для API мне кажется перебором, как Django для этих целей использовать — можно, но зачем?

Спасибо за ответ, буду ковыряться, я дотошный)))
НЛО прилетело и опубликовало эту надпись здесь
Вы спрашиваете что-то вроде: «а как мне выкинуть из Catberry основную часть и использовать вместо выкинутого куска React, но так чтобы вы все остальное работало также». Серьезно?
Если я правильно понял, то автор не имел ввиду выбрасывание чего-то из Catberry, а говорил, что ему понравился React, но так как в Catberry были шаблоны, то он ему не подошёл.
Спасибо за ответ.

Вы спрашиваете что-то вроде: «а как мне выкинуть из Catberry основную часть и использовать вместо выкинутого куска React, но так чтобы вы все остальное работало также»

Нет же. Я просто сказал, что мне хочется именно реакт с его компонентами.

текущая архитектура и подход React никогда не позволят ему реализовать прогрессивный рендеринг

К сожалению приходится чем-то жертвовать.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо!
А какие вещи, например, сделаны не совсем правильно?
MemoryStorage, например, не должен ничего знать о HTTP и, тем более, не должен бросать HTTP ошибку.
Ошибки в app.js лучше проверять одним try-catch блоком, чтобы не возникало повисших соединений.
Ещё в MemoryStorage мы явно возвращаем Promise. Это можно избежать, если функция явно объявлена как async.
Ну и надо писать больше тестов :)

Уверен, есть ещё недочёты, но пока не могу их вспомнить.
Есть вопрос.
Action — это же функция, возвращающая результат. Если я вызываю action из компонента и не пользуюсь результатом, а жду изменения из хранилища — это потому, что я такой ответственный? Если да, то, разве это не странный дизайн? Или я что- то упустил?
Да, с виду это немного странно. Но суть здесь в том, что на один Store может быть подписано несколько компонентов, и при его обновлении, обновятся все связанные компоненты.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.