Ajax
JavaScript
ReactJS
Comments 17
+2
Обратите внимание, это листинг всего исходного удаленного компонента, здесь нет никаких подгрузок модулей import… from… или… = require(...) из node_modules, иначе работать не будет.


А в чем проблема доверить сборку тому же webpack-у и держать на стороне сервера готовый бандл?
Да, и компонент может быть и функцией (что вполне оправдано если у нас stateless компоненты)

Я без троллинга, вопрос реальный — были подводные камни или просто не рассматривали такой вариант?
0

Если не добавлять в компонент require('react') или import React from 'react', нет смысла гонять это вебпаком, если внутри вебпак все равно использует бабел. Вот поэтому я напрямую бабелем и подготавливаю.


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

+1
>если внутри вебпак все равно использует бабел.

Ну использовать бабель вы ему сами говорите. Если не нужен — можно и не использовать, но это, имхо, не столь важно. Речь о том что Ваше решение отбрасывает любую возможность использовать 3-party компоненты, что как то и не айс — все самому что ли ваять ручками?

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

Да, согласен, у меня к концу проекта удаленный компонент разросся до 2к строк и встал вопрос о третесторонних модулях, о том как вынести общий функционал для некоторых компонентов.
Как вариант да — делать ручками, но я не решился.
Это одна из причин написания статьи, может быть кто-то делал по-другому и решал такие проблемы.

0

Чтобы не включать всюду реакт вебпаку в конфигурации можно указать externals.
В целом же, по-моему, затея сомнительная и не понятно как решить какие данные ему скормить (в примере только текущая дата).
Интересно узнать какая за этим бизнес-задача стояла :)

+1

Могу рассказать, что стояла задача примерно такая.
Есть список пользователей.
При просмотре каждого пользователя формируется url:
/user/{template}/{user_id}
Нужно было внедрить шаблонизатор для просмотра пользователя.
допустим
/user/table/1 — показать 1-го пользователя в табличной верстке
/user/flex/1 — показать 1-го пользователя в резиновой верстке
/user/.../1 — показать 1-го пользователя в…
и так далее, используя удаленные компоненты "представление" пользователя можно сделать независимым, его может делать другой человек и можно сделать сколько угодно таких тем для показа пользователя.

0

Так обычно просто команда работает с разными ветками и потом просто сливает все в одну, совместив таким образом все представления?

0

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

+1

Я не спец по безопасности, но делать руками new Function() это как eval вызывать. Я бы сто раз подумал, прежде чем пытаться такое провернуть.
Есть SystemJS. Он всё, что вам нужно, умеет.

0

Я тоже не спец, я сразу сказал заказчику, что это небезопасно.
Хотел об этом пару строк написать в статье, но думаю многие знают.

+1

А для чего было сделано это извращение?
Зачем нужно иметь возможность менять компоненты на сервере?
Почему не стандартный способ с обычными компонентами + json по сети?


Расскажите, пожалуйста, про применение этого способа.

Only those users with full accounts are able to leave comments. , please.