How to become an author
Search
Write a publication
Pull to refresh

Comments 34

Немного отвлеченно, вставлять html разметку в код теперь считается круто?
Total votes 18: ↑11 and ↓7+4
{«круто»: «высокий стиль арихитектуры разработки»}
Total votes 6: ↑4 and ↓2+2
Вообще конечно вопрос интересный. Делать вещи в духе 
 $('selector').append('<div>something</div>')
не очень круто. А подход реакта — вполне. По крайней мере разработчики считают, что так как компоненты не столько меняют DOM, а просто генерируют дерево абстарктных объектов, то почему бы не засунуть код, возвращающий это самое дерево, прямо в код компонента? Вполне логичное решение, ИМХО.
Total votes 7: ↑7 and ↓0+7
Интересный момент в том, что в PHP, откуда, видимо, создатели и черпали вдохновение, уже много лет считается хорошей практикой не смешивать HTML и логику. Именно на этом настаивают сторонники дополнительных шаблонизаторов в PHP, который сам по себе неплохой шаблонизатор.
Total votes 14: ↑4 and ↓10-6
Ну насколько я себе понимаю то, что предлагает Реакт (по крайней мере я так стараюсь реализовывать код на нём в своих проектах), логика и так должна быть отделена от представления. Компонент занимается только переносом состояния в верстку. Вся бизнес-логика сидит отдельно.
Total votes 11: ↑11 and ↓0+11
Не путайте «бизнес логику» и «логику отображения». Некоторые в PHP комьюнити, знаете ли, до сих пор в базу из view лезут.
Total votes 8: ↑8 and ↓0+8
В императивной шаблонизации я сторонник подхода, при котором представление — это практически чистый HTML, код в котором ограничивается выводом значений переменных, циклами, ну, может, еще какими-нибудь элементарными вещами. Мне кажется, что много HTML — мало кода читается гораздо лучше и выглядит гораздо чище, чем много HTML и много кода. А уж о бизнес-логике в представлении и речи не было.
This comment wasn’t rated yet0
Я полностью с вами согласен.
Total votes 1: ↑1 and ↓0+1
При использовании lazy loading и прочих абстракций типа прокси и декораторов залезть в базу через какой-нить геттер вполне нормально, даже если она меняется при этом (например, пишется лог обращений к записи).
This comment wasn’t rated yet0
ну тут мы не в базу лезем, а забираем кусок состояния объекта, то что при этом залазит в базу что-то это уже мелочи. Вью от базы в этом случае не зависит.
This comment wasn’t rated yet0
JSX не является разметкой. А смысл функции render отдать virtual dom.
Total votes 5: ↑4 and ↓1+3
Не круто, но если это действительно становится проблемой (а до определённого предела это лишь академическое замечание), то я уверен, что можно вынести шаблоны в отдельные файлы и использовать шаг сборки: gulp, плагины browserify для инклуда файлов и т.п.

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

Лично для меня это не является проблемой, потому что можно вообще не использовать JSX. По какой-то причине я не полюбил JSX, хотя до этого имел дело, например, с Ангуляром и Vue, которые постулируют похожий подход работы с разметкой. Использование чистого JS видится мне более гибким и компонуемым.
This comment wasn’t rated yet0
Не заметил чтобы Ангуляр постулировал размещать разметку внутри кода, да такая возможность есть, но как правило на практике используют шаблоны в виде внешних html, плюс кешируют их заранее при сборке (во избежании доп. запросов).
Total votes 2: ↑2 and ↓0+2
Немного отвлеченно, вставлять html разметку в код теперь считается круто?

Тут зависит от того, кто автор фреймворка. От facebook — это OK, создали новую парадигму, от Васи Пупкина — загнобили бы.
Total votes 25: ↑18 and ↓7+11
К сожалению, отделять логику от представления в js очень сложно. Я несколько раз наблюдал раздутые шаблоны на каком-нибудь хенделбарс, с кучей хелперов, в итоге, в шаблоне получается адская смесь из: 1) html, 2) js 3) кода специфичного шаблонизатора.
facebook не стал бороться, просто убрали синтаксический шум из кавычек, переносов слов, запилили интерполяцию строк. Компоненты на много гибче и проще, чем с вынесенным отдельно шаблонизатором. Да и вообще, никто не мешает писать что-то типа: 
React.createElement("div", null);
Total votes 9: ↑9 and ↓0+9
Полностью согласен. По факту вы генерируете DOM дерево. Никакого HTML в JS нет и в помине. JSX так же опционален, как и любой другой препроцессор([coffee,type,pure]script). Смущает XML-синтаксис в JS — пишите в объектной нотации, кто ж запрещает?
Total votes 5: ↑5 and ↓0+5
Угу, я на это не явно и намекал.
This comment wasn’t rated yet0
Автор ничего не сказал про переносимость компонентов реакта. Могу я один и тот же компонент, однажды написанный, использовать в разных проектах? Так, чтобы без копипасты?
Total votes 3: ↑3 and ↓0+3
Я думаю вы всегда можете оформить свой компонент как npm модуль и подгружать его куда хотите
Total votes 2: ↑2 and ↓0+2
По поводу server-side рендеринга, тут дело нодой не ограничивается, я например делал изоморфное приложение на Clojure + Om (ClojureScript обертка над ReactJs) и рендерил на сервере с помощью Nashorn, который появился в Java 8. Работало прекрасно.
Total votes 1: ↑1 and ↓0+1
Это я так, вне работы балуюсь.
А насчет стека — что так удивляет?
На кложе, не поверите, очень приятно писать: ФП, трансдьюсеры, иммутабельность, lazy-seqs, core.async, интеграция с JVM и возможность использования модулей на Java/Scala/..., core.typed там, вот это вот все… хотя последнее скорее костыль пока.
Очень уж лаконично и красиво получается все в целом.
Ах да, я еще и Datomic использую (http://www.datomic.com/), так что у меня еще и база на кложе. ;)
This comment wasn’t rated yet0
Да я в позитивном смысле, на самом-то деле. Clojure и edn мне тоже импонируют.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Так JSP компилирется в стандартный Java класс (сервлет), конечно обработка будет быстрой.
This comment wasn’t rated yet0
Ничуть не смущают теги в JS, так или иначе генерация компонентов на JS к этому приводит, но на разных уровнях. Гораздо важнее один из пунктов статьи, про побочную сложность, дырявые абстракции и актуальность библиотеки через год-два. С другой стороны, волка бояться, так и продолжать писать на низком уровне, без абстракций и плюшек.
This comment wasn’t rated yet0
Упрямая архитектура (Opinionated Architecture)
Обычно — «жёсткая архитектура (фреймворка)».
This comment wasn’t rated yet0
С 5 пунктом я бы поспорил.
Дело в том, что реакт рендерится на сервере крайне неэффективно.

Оба метода, которые преобразуют компонент в строку (renderToString и renderToStaticMarkup) на каждую ноду вызывают свое преобразование. А вызов функции это более-менее затратная операция.

Я проверил на синтетическом тесте, в сравнении с *любимым шаблонизатором*
jsperf.com/react-rendertostring/7 — строится список из 100 элементов, у реакта производительность в десятки раз ниже.

Я пока в самом начале пути освоения реакта, но меня это настораживает. А еще больше настораживает что информации об этом не так много.
This comment wasn’t rated yet0
Если поисковики (для которых вы и будете рендерить на сервере страницу) заходят на ваш сайт чаще реальных пользователей (где все это будет на клиенте), то это значит что не библиотека неэффективна, а сам сайт ваш не эффективен :)
Total votes 1: ↑0 and ↓1-1
То есть реакт не подходит, если есть требование чтобы страницы для клиентов рендерились на сервере. В статье же написано что «Реакт можно использовать для подачи статичной разметки, без клиентского кода вообще.»
Total votes 1: ↑0 and ↓1-1
Ну, я бы не стал его так использовать точно — это очень странно. В статье это написано в контексте доступа к контенту сайта поисковиками, т.е. можно делать нормальный динамический контент для людей и поддержать еще и отдачу контента поисковикам.
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr