Нужно ли включать маршрутизатор в изоморфную часть?

Question

[Макс Сысоев]

Речь идёт о маршрутизаторе react-router, но это не особо важно. Я попробовал включать маршруты клиентской части в серверную и нет - оба варианта. И не могу теперь определиться, что из этого лучше. Интересует выбор для изоморфного приложения, скажем, интернет магазина.

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

Речь идёт о маршрутах с данными (типа страницы товара, каталога - с запросом в БД), так и статических страницах (вообще без запросов к БД)

Я немного помогу отвечающим и опишу оба подхода более детально.

Если мы включаем маршруты, то:
Изоморфная часть React становится middleware.
+

• DRY для клиентских маршрутов - не нужно их описывать в серверном маршрутизаторе
  

-

• Появляется головная боль с получением данных до отрисовки (в FB придумали Relay как решение)
  
• Трудности с определением исключений, например, 404. Заодно и двойная отрисовка приложения, если попали на маршрут 404
  

Если мы не включаем маршруты, то:
Изоморфная часть React очень похожа на обычные шаблоны типа Jade.
+

• С получением данных нет проблем
  
• Статические страницы выводятся через продублированный на сервере маршрут
  

-

• Описываем маршруты дважды (повторяем себя)
  

Вся проблема именно в дублировании... Может, не так страшен чёрт, как его малюют?

Answer 1

[Алексей Куреев]

Прошу прощения, но я не понимаю, о каких проблемах с получением данных Вы говорите в первом варианте. Выглядит всё не так страшно: каждый React класс может иметь статические методы, в которые вы можете вынести вызов функций, которые сделают fetch ваших данных. Вы можете посмотреть как я это сделал у себя в коде.

И вот по поводу 404.

Comments

[Макс Сысоев]

То, что нужно. Один вопрос - серверный superagent не проседает по производительности при масштабировании?

[Алексей Куреев]

Честно сказать, не знаю. Этот пример я делал исключительно для демонстрации своей реализации изоморфной Flux архитектуры, никогда не использовал в бою. Но полагаю, что на сервере оно использует нодовский http, так что если вас устраивает его производительность, то при работе с superagent вы не должны почувствовать разницу

Answer 2

[Тимур Шемсединов]

С дублированием сложно смириться морально. Но есть три пути, два Вы описали, дублировать и изоморфить. Но мне больше по душе третий, когда серверная часть содержит все в себе, обобщенную решаемую задачу и динамически порождает клиентскую часть. То есть, нужно не 2 раза писать, а используя метапрограммирование подняться на такой слой абстракции, где нет клиента и сервера и там решать задачу, а потом транслировать ее в клиент и сервер, в шаблоны и маршруты в конкретику.

Comments

[Макс Сысоев]

Спасибо за ответ! Совсем про это забыл. Короче говоря, абстрагироваться :) Такой подход используется в fullstack JS фреймворках, типа Derby и Meteor, верно?

Существование такой штуки под react-router + Hapi тоже сомнительно, к сожалению.

У меня была мысль написать что-то попроще - типа файла конфигурации для обоих типов маршрутов, но потом понял, что это слишком много накладных трудов для такой маленькой части приложения как маршруты (ведь это дело поддерживать потом).