LINUX.ORG.RU

ReactJs и НЕ SPA

 


0

2

Добрый день.

Смотрю в сторону ReactJs и на поверхности всплыл один глобальный вопрос.

Можно ли ReactJs использовать не в SPA приложениях? Т.е., рендер html производит сервер (PHP), а React только для динамических интерфейсов над этим отрендеренным сервером представлением - что то вроде, как сейчас с jQuery.

На первый взгляд не вижу развития такого сценария, потому что вроде если сервер будет рендерить html, то представление срендеренное на сервере должно иметь точное соответствие с тем представлением, которое рендерит компонент ReactJs и получается, что как минимум поддерживать одинаковый рендеринг html на сервере и на клиенте в ReactJs будет ужасно.

Изоморфное приложение - это вроде тоже SPA, с рендерингом на сервере средствами ReactJs, а меня интересует именно та ситуация, когда типовой рендеринг html на сервере средствами (php) и динамика на стороне клиента - как это было раньше через jQuery.

Можно ли как-то реализовать это с ReactJs?

Спасибо.

Ну ты же JQuery не рендеришь на сервере. Можешь точно так же отдельные контролы делать на реакте и там React.render(<MyControl />, document.getElementById('my-control'))

zz ★★★★
()
Ответ на: комментарий от zz

Да, но проблема то остается в том, что: - На сервере рендерю (не ReactJs) всю страница в html; - На клиенте через компонент ReactJs рендерю предположим только «фильтр товаров» из всего представления, пришедшего с сервера.

через время нужно изменить отображение «фильтра товаров» - мне придется переписывать html представление в двух местах, на сервере и на клиенте в компоненте ReactJs.

А если таких динамических фрагментов на странице 30-40, а страниц в приложении 20-30, то ...хм..

stranger-ru
() автор топика
Ответ на: комментарий от stranger-ru

Тут вариантов не много: 1) не рендери на сервере. 2) рендери базовую разметку для поисковиков React.render() там все заменит внутри все равно.

zz ★★★★
()
Ответ на: комментарий от zz

Получается так, но, почему же я изначально не хочу SPA или изоморфное приложение. Потому что (например) у меня на сервере крутится тот-же RBAC, через который я контролирую доступ по ролям к действиям и к страницам, а так-же генерю html страниц в соответствии с этими ролями и правами доступа. Перетащить RBAC на клиент - это жуть. Да и не только в RBAC дело.

stranger-ru
() автор топика
Ответ на: комментарий от zz

1) не рендери на сервере. 2) рендери базовую разметку для поисковиков React.render() там все заменит внутри все равно.

Вот что еще не маловажно, а если у пользователя отключен JS в браузере, то все пропало.

stranger-ru
() автор топика
Ответ на: комментарий от stranger-ru

у пользователя отключен JS

Нет таких пользователей, особенно у магазинов :) Если он и есть - они не делают столько прибыли чтобы ради них что-то делать.

Если у тебя все JQuery - это какие click хендлеры, которые загружают и вставляют в дом html - вряд ли тебе сильно упростит жизнь реакт. И наоборот, если у тебя реально сложные контролы, вряд ли ты сможешь получить полную их разметку на сервере не копируя логику с клиента. И они все равно не будут работать без JS. Например, слайдеры, динамические графики какие нибудь - тут либо отдавать с сервера то, что работает без JS, либо разметку как будет с клиентским фреймворком, и то и то сразу - не получится.

zz ★★★★
()
Ответ на: комментарий от zz

Понятно, спасибо. Сделал вывод, что все таки ReactJs больше для SPA приложений хорош.

stranger-ru
() автор топика

Одному мне кажется этот react антипаттерном? Какой-то клиентский похапе. Как там с ним верстальщики работают? Не вешаются? Или теперь уже нет верстальщиков, одни программисты на клиенте?

anonymous
()
Ответ на: комментарий от anonymous

Не одному, но таких увы мало. Прямо сейчас рабираю по кирпичикам полимер-приложение, не react конечно, но это просто кем надо быть чтобы такие фреймворки придумывать.

Ей богу, после этих новомодных гениальных вещей, связка php + татика + jQuery кажется просто идеальным технологическим решением.

ixrws ★★★
()
Ответ на: комментарий от anonymous

Или теперь уже нет верстальщиков, одни программисты на клиенте?

Да.

Deleted
()
Ответ на: комментарий от ixrws

Это все ради СЕО и только ради СЕО. С технической точки зрения всякие изоморфные приложения огромнеший и ненужный оверхед.

anonymous
()
Ответ на: комментарий от stranger-ru

На сервере с помощью php или чего бы там ни было другого ты ни за что не составишь разметку которую клиентский реакт сможет подхватить. Поэтому здесь есть только один вменяемый вариант, либо настоящее изоморфное приложения с бекендом на ноде, либо из php (если оставить за скобками то что в 2015 году писать на пхп это моветон) дергать ноду которая будет рендерить через React.renderToString и отдавать готовую разметку, которую уже клиентский реакт нормально подхватит. В таком случае у тебя на сервере опять рендериться будут те же компоненты что и на клиенте, и ничего два раза реализовывать не надо. Насколько мне известно, годные реализации такого вариант существуют для раби-он-раилс и цэшарпа, с пулом процессов ноды для рендеринга, и прочими плюшками.

anonymous
()
Ответ на: комментарий от ixrws

Не мало, таких большинство, кто не понимает в чем разница между jsx и php, и почему один из них не нужен от слова совсем, а другой - будущее фронтэнда.

anonymous
()
Ответ на: комментарий от anonymous

Ой как уж поднадоело это, даже на моей памяти сменилось как минимум два поколения этих - будущих чего-то там. А уж если почитать, то окажется что этих будущих была целая тьма.

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

Ирония в том, что javascript стал популярным ровно потому же, почему и php - простота, выразительность, лёгкий старт. А потом пришли «инноваторы» и показали как правильно надо писать на жабаскрипте. Так вот jQuery это правильно, а этот ваш реакт - промывка мозгов, которая всё равно не заменит проектирование. Ой, вот она тайна, приложение спасает не инструмент, а проектирование.

ixrws ★★★
()
Ответ на: комментарий от ixrws

Прямо сейчас рабираю по кирпичикам полимер-приложение
но это просто кем надо быть чтобы такие фреймворки придумывать

Полимер (web components), кстати, решает другую фундаментальную проблему. И да, красивое решение проблемы, и обкладывание костылями, кажущееся решением - суть разные вещи.

anon1984
()
Ответ на: комментарий от anon1984

Это как? Реакт что, делает что-то такое чего нельзя запроектировать в своём приложении(то есть сделать свой react, если конечно мозг такой же гнилой как у реактовцев).

Забавнее всего выглядит то, как народ закапывал xbl и потом чуть ли не всё те же люди стали форсить эти новые генераторы html.

ixrws ★★★
()
Ответ на: комментарий от anon1984

Да откуда ж вы взялись то, искатели проблем. Реальность такова, что на дельфях народ писал системы значительно сложнее любого современного сайта используя одни только формочки, гриды и sql. И да, это работало быстрее, а ещё и на железе раз в 10-20 хуже.

Чтобы решать проблему, надо сначала найти тех кто способен увидеть проблему и найти решение. Эти бы сразу заметили, что ВНЕЗАПНО, html это язык разметки, а не язык для определения ui.

ixrws ★★★
()
Ответ на: комментарий от ixrws

Ой как уж поднадоело это, даже на моей памяти сменилось как минимум два поколения этих - будущих чего-то там

Чисто из любопытства - как их звали?

tailgunner ★★★★★
()
Ответ на: комментарий от ixrws

React это и есть дельфи для веба — компонентная рисовалка интерфейсов.

PolarFox ★★★★★
()
Ответ на: комментарий от ixrws

Реакт что, делает что-то такое чего нельзя запроектировать в своём приложении?

ЭВМ что, делает что-то такое чего нельзя рассчитать на деревянных счетах?

ЯВУ что, делает что-то такое чего нельзя написать в машинных кодах?

Интегральное исчисление что, делает что-то такое что нельзя вычислить без него в моем расчете?

Можно, смотри про костыли. Еще есть цитата про сложный программный продукт и лисп-систему.

anon1984
()
Ответ на: комментарий от tailgunner

Какой вопрос, такой ответ: xbl, asp.net. Нужно продолжать, гуголь Вас ждёт. Да, это разные вещи, а не поколения. Ну ладно, можно ещё вспомнить cappuchino, enyo.

Разница между многими этими «проектами будущего» в основном в том, кто их форсит. реакт с полимером форсят фб да гуголь, у них тариф безлимитный. Они для it сообщества как Путин для россиян.

ixrws ★★★
()
Ответ на: комментарий от anon1984

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

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

ixrws ★★★
()
Ответ на: комментарий от ixrws

Ой как уж поднадоело это, даже на моей памяти сменилось как минимум два поколения этих - будущих чего-то там

Чисто из любопытства - как их звали?

Какой вопрос, такой ответ

Ты сам-то знал, о чем говорил? Ладно, не хзаморачивайся.

tailgunner ★★★★★
()
Ответ на: комментарий от ixrws

он стал сложным именно потому что каждый хочет наплодить новую вещь поверх старой

Не только, бывает еще объективная сложность.

anon1984
()
Ответ на: комментарий от ixrws

Знал, и ты знал тоже

Я не телепат, к Веб уже лет 15 отношения не имею вообще никакого, а из традиционных GUI пользовался только PyGtk (когда-то и PM, но это не в счет). Почему ты решил, что я что-то знаю, для меня загадка.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от ixrws

Это не безумие, но реальность. Все эти слои придуманы как раз для того что бы убрать сложность. Для того что бы разрабатывая формочку для заказа пиццы я мог проектировать ее не в терминах регистров процессора и инструкций которые двигают данные между ними, но в терминах текстовых полей и кнопочек.

anonymous
()
Ответ на: комментарий от anonymous

Внезапно! Это давал motif поверх x window в мохнатых годах. Не надо путать наличие множества слоёв и предназначение каких-то конкретных из них.

ixrws ★★★
()

React без проблем рендерится на сервере, что душевно повышает отзывчивость морды. На Reagent кложуристы тоже замутили такую фичу.

Hertz ★★★★★
()
Ответ на: комментарий от ixrws

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

anonymous
()
Ответ на: комментарий от anonymous

Если бы ты изучил историю, то увидел бы там много раз это «недолго уже осталось». Понимаю, сложно видеть что-то хотя бы за период 20 лет и тем более находить общие момент. Но ещё недавно winapi была на почти любом компьютере и носимом компьютере. И казалось что ещё чуть чуть и оп, а видишь как вышло, появились новые игроки и оп не случилось. И это было недавно.

Обычно же ситуация складывается следующим образом: какая-то технология доходит до пика, потом по разным причинам всё начинают переизобретать заново. Так вот скоро, лет через 5 или раньше, история вновь повторится.

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

ixrws ★★★
()

Изоморфное приложение - это вроде тоже SPA, с рендерингом на сервере средствами ReactJs, а меня интересует именно та ситуация, когда типовой рендеринг html на сервере средствами (php) и динамика на стороне клиента - как это было раньше через jQuery.

Можешь, конечно. Но тебе придётся всё писать два раза — один раз на PHP, один раз на JavaScript и сверять, что у тебя получаются идентичный текст. Вообще смысла в этом мало. Гугл нормально индексирует JS-сайты. Пользователям тем более пофиг.

Legioner ★★★★★
()

SPA - это тормозня, зачем то эмулирующая клиентское приложение в браузере? Эталонное ненужно. Кстати, я бы на месте фанатов этого треша поостерегся с планами глобального господства. Тенденция перетаскивания сложной логики в нормальные толстые клиенты налицо, на мобилках так в полный рост. Браузерные ОС тоже зафейлились, а сколько было апокалиптичных вангований на их счет. Против природы не попрешь и из говна конфетку не слепишь.

anonymous
()
Ответ на: комментарий от anonymous

Я сам не пробовал, но в теории у Java есть JavaScript-движок, в котором можно выполнять тот же React без всяких нод.

Legioner ★★★★★
()
Ответ на: комментарий от menangen

Что сложного в реакте? Для работы с ним нужно всего две вещи: dispatch: state -> state и render: state -> VirtualDOM, все, больше в приложении ничего нет.

anon1984
()
Ответ на: комментарий от Deleted

Быть может, хотя конечно у меня иное мнение:)

ixrws ★★★
()
Ответ на: комментарий от anonymous

Забавное дело, но SPA полностью написанное на javascript, при проектировании которого учитывались многие нюансы(вроде того, что работать с DOM надо примерно как делают это в нормальных ui тулкитах, а не постоянно перезаписывать как это делают вебники) работают очень даже шустро. Конечно сравнивать с qml или даже gjs не получится, будет куда хуже, но где-то уровень xul можно получить. Для многих задач такого не слишком быстрого ui вполне достаточно.

Но вебники просто пропагандируют иной подход, не все конечно, который и делает супертяжеловесные сайты.

ixrws ★★★
()
Ответ на: комментарий от ixrws

а не постоянно перезаписывать как это делают вебники

Похоже, ты о реакте и никакого представления не имеешь. man virtual DOM

Deleted
()
Ответ на: комментарий от Deleted

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

Да, virtual DOM уменьшает количество обращений, в сравнении с прямой работой с деревом. Но сам подход работы остаётся прежним. Это происходит потому, что разработчики те же и подходы у них те же. Поэтому на практике facebook томозит, а вконтакт почти не тормозит. А разница в разработчиках.

Такой простой пример: в обычном ui принято обращаться к элементу имея ссылку на него заранее, даже когда ui подгружается из xml, то есть подход аналогичен работе с динамическими библиотеками. В веб куда чаще можно встретить сначала поиск элемента, а потом обращение к нему. И тут конечно важно где поиск идёт(в реальном или виртуальном DOM), но это несопоставимо с случаями обращения без предварительного поиска. И это конечно не единственный «нюанс».

ixrws ★★★
()
Ответ на: комментарий от ixrws

Ну в общем ajax, json, jquery, react - поворотные точки на фронтенде. Это видно невооруженным так сказать :)

zz ★★★★
()
Ответ на: комментарий от ixrws

В веб куда чаще можно встретить сначала поиск элемента, а потом обращение к нему

Кстати, да. Офигеваю, как жоэсники лихо гоняют по дереву каждый раз, когда нужно обратиться к элементу. Что там под капотом никто не задумывается. Ну ладно, когда это в скрипте на 10 строк, пофиг. Но потом этот рак разрастается, начинается тормозня, а жоэсник даже не вкуривает где может быть проблема. Это Файрфокс тормозит!!!11

anonymous
()
Ответ на: комментарий от ixrws

Если про реакт, в виртуальном dom вообще никто ничего никогда не ищет. Зачем? Всегда есть отдельный стейт, в виде JS объектов (Мапы, массивы и прочее), там все нужное. Есть _очень_ редкие исключения - например, выяснить реальный BoundingBox отрендеренного элемента, в 99% приложений оно не нужно.
Я уже писал про чистые функции и направленность DataFlow в реакте, но у тебя либо валенок вместо головы, либо ты даже минимально матчасть не читал.

anon1984
()
Ответ на: комментарий от zz

Нет таких пользователей

Есть

особенно у магазинов

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

Если он и есть - они не делают столько прибыли чтобы ради них что-то делать.

Увы.

dexpl ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.