Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Это такое гибридное (хотя это не совсем правильный термин) приложение, которое использует один и тот же код для рендеринга на клиенте (в данном случае в браузере) и на сервере. Это позволяет не дублировать логику и шаблоны, как в случае с обычными приложениями. Это можно проиллюстрировать такой картинкой:
Картинка
еще в копилку полезного чтения: www.smashingmagazine.com/2015/04/21/react-to-the-future-with-isomorphic-apps
Спасибо за статью. Познавательно
Подскажите, можно ли как-то ускорить webpack в вашей демо? У меня на Atom машинке оно собирается больше трёх минут. Кеширование почему-то вообще не попадает.
Мы с друзьями собираемся попробовать JS для нового проекта, сейчас мы живём на Python (в большей степени на Django замученной до Flask) и по большому счёту нам всё нравится кроме случаев, когда проект развивается в сторону клиентской части (JS).
Отсюда есть желание найти «идеальный инструмент в мире JS» и оставить Python для background задач.
На первый взгляд мне понравилось ваше Demo, но чтобы не было мучительно больно потом, я бы хотел задать несколько вопросов сейчас:
1. Практичен ли описанный вами набор компонент для строительства большого проекта?
2. Какие подводные камни вы знаете/подозреваете?
3. Какие-нибудь комментарии относительно производительности babel, NodeJS и других причастных?
4. Может вы встречали другие серебрянные пули? :) (Например, у меня вот просто несваримость с Vanilla JS и если бы не ES6/ES7, я бы не рискнул нырять в этот мир JS)
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. Всё в целом хорошо, но хранение переводов — небольшая боль. Нет дефолтных переводов, надо везде таскать все переводы для текущего состояния иначе ловим исключения. А ещё нужно приучить себя всегда закрывать теги:
3. babel просто транслирует ES6/ES7 → ES5, он не выполняет код сам. Node.JS шустрая, основной затык обычно в запросах к БД. А вот с React на сервере уже не всё так хорошо. Синтетические тесты (ab -c 5 -t 10 ...) TODO списка на моём i7 с 8GiB памяти показали всего лишь около 200RPS, что не очень плохо, если сравнивать с каким-нибудь PHP. Но довольно медленно, если сравнить с другими шаблонизаторами на Node.JS. И при увеличении количества компонентов, которые рендерятся для текущего состояния, производительность продолжает падать. Этого можно избежать в некоторых случаях, если использовать некоторые оптимизации.
4. серебрянной пули не существует :) Уже давно существуют всякие Meteor'ы, Derby.JS и т.д. Но это полноценные фреймворки и иногда с ними нужно бороться, чтобы сделать что-то нестандартное (сам не работал, но знающие люди так говорят).
Желаю удачи в вашем проекте :)
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? Он не использует 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 смотрел несколько месяцев назад, но тогда мне не понравилось, что нужно компоненты держать в 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 :)
Если у вас появятся какие-то комментарии к моему потоку мыслей — я буду очень благодарен.
Пока что 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 сервера?
Какие языки/фреймворки/библиотеки вы используете для 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.
Ну и надо писать больше тестов :)
Уверен, есть ещё недочёты, но пока не могу их вспомнить.
Ошибки в app.js лучше проверять одним try-catch блоком, чтобы не возникало повисших соединений.
Ещё в MemoryStorage мы явно возвращаем Promise. Это можно избежать, если функция явно объявлена как async.
Ну и надо писать больше тестов :)
Уверен, есть ещё недочёты, но пока не могу их вспомнить.
Есть вопрос.
Action — это же функция, возвращающая результат. Если я вызываю action из компонента и не пользуюсь результатом, а жду изменения из хранилища — это потому, что я такой ответственный? Если да, то, разве это не странный дизайн? Или я что- то упустил?
Action — это же функция, возвращающая результат. Если я вызываю action из компонента и не пользуюсь результатом, а жду изменения из хранилища — это потому, что я такой ответственный? Если да, то, разве это не странный дизайн? Или я что- то упустил?
Да, с виду это немного странно. Но суть здесь в том, что на один Store может быть подписано несколько компонентов, и при его обновлении, обновятся все связанные компоненты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание изоморфного приложения на React и Flummox