Комментарии 34
Предлагаю еще посмотреть в сторону webpack, сам раньше всегда использовал requirejs, но оказалось что писать загрузку модулей с commonjs удобнее и красивее
+5
мне CommonJS тоже нравится больше, однако мне почему-то жутко не нравится куча var-ов на каждую переменню. Одна var на все эти переменные тоже не сильно нравится… :) Вот import из ES6 было бы круче всего, как по мне.
0
можно взять 6to5, 6to5.org/docs/usage/modules/ там все это есть :)
а с кучей var тоже просто.
var React = require('react'),
Component = require('./component')
:)
а с кучей var тоже просто.
var React = require('react'),
Component = require('./component')
:)
+2
Смотрите в сторону DI (dependency injection) менеджера, чтобы избавиться от var'ов, получить более элегантый и удобный для тестирования код.
Вот простой пример:
Code source.
Вот простой пример:
/** @jsx React.DOM */
let appRenderInit = (app, window, $, React, Hello, World, undefined) => {
'use strict';
return (element) => {
var Index = React.createClass({
render() {
/* ... */
}
});
React.render(<Index />, element);
};
};
export default appRenderInit;
Code source.
+4
Спасибо, обязательно посмотрю.
0
Заголовок был многообещающим, а по факту не понятно как вы собираетесь передавать данные из моделей, будете ли использовать Бекбон вью и т.д.
+3
нуб-вопрос про весь этот реакт/ангуляр/эмбер:
получается что вся страница собирается уже на клиенте, как обстоят дела с индексацией роботами и как увидят сайт пользователи, например ИЕ8 (да, приходится поддерживать)
получается что вся страница собирается уже на клиенте, как обстоят дела с индексацией роботами и как увидят сайт пользователи, например ИЕ8 (да, приходится поддерживать)
0
Если вы специально не позаботились, то роботы ничего не увидят.
Поддержки IE8 в Ангулар нет, в Реакте через полифилы и придется шаблоны прекомпилять. Про Эмбер не знаю. Если кратко, то очень плохая. Но на мой взгляд это закономерно.
Поддержки IE8 в Ангулар нет, в Реакте через полифилы и придется шаблоны прекомпилять. Про Эмбер не знаю. Если кратко, то очень плохая. Но на мой взгляд это закономерно.
0
Информация касательно индексации таких приложений яндексом.
0
По ссылке:
Другими словами: яндекс не умеет индексировать ajax (да и просто сгенерированные на клиенте) страницы.
Каждая индексируемая AJAX-страница должна иметь HTML-версию
Другими словами: яндекс не умеет индексировать ajax (да и просто сгенерированные на клиенте) страницы.
0
Получается что так. Логику подстановки данных в html шаблон придется реализовывать в двух местах, на клиенте для людей и сервере для Яндекса, Google и т.д.
Кстати, если ваша серверная часть написана на node.js, можно реализовать пререндеринг страниц на стороне сервера.
Кстати, если ваша серверная часть написана на node.js, можно реализовать пререндеринг страниц на стороне сервера.
0
Для Google уже давно не нужно делать пререндеринг, crawler понимает js.
+1
Можно рендерить на бекенде страницы, а потом поверх запускать фронтэнд приложение. По крайней мере так на backbone делаем
0
prerender.io в помощь
0
>>Всё и сразу пока не работает.
Убило наповал. Зачем статья?
Зачем тащить было в проект Backbone и requirejs? Обоснование отсутствует. Вы не понимаете Flux, поэтому притащили в проект Backbone? Или в нем есть необходимость, потому что Flux не устраивает этим и этим?
React + Flux + 6to5 + webpack избавляет от прошлого века requirejs.
Фига себе прозрачность в контроллерах Backbone находятся компоненты React.
Убило наповал. Зачем статья?
Зачем тащить было в проект Backbone и requirejs? Обоснование отсутствует. Вы не понимаете Flux, поэтому притащили в проект Backbone? Или в нем есть необходимость, потому что Flux не устраивает этим и этим?
React + Flux + 6to5 + webpack избавляет от прошлого века requirejs.
Фига себе прозрачность в контроллерах Backbone находятся компоненты React.
+1
А насколько у webpack хорошо с компиляцией в рантайме? Я вот поставил requirejs с jsx плагином и могу все на живую компилировать, никаких watcher'ов и т.п., webpack же, насколько я понимаю, заставит меня через свой сервер ходить для этого.
0
Если вы не хотите использовать watcher-ы, то это ваши проблемы. Можете не использовать.
Можно компилировать наживую, через watcher-ы, через watcher wabpack или запускать webpack для сборки. Как настроите так и будет.
Я совсем не использую requirejs т.к. это устаревшая технология, уже можно использовать es6 и es6 модули. Если проект новый и нет предрассудков и каких-то страхов, то зачем использовать устаревшие инструменты, когда есть современные?
Можно компилировать наживую, через watcher-ы, через watcher wabpack или запускать webpack для сборки. Как настроите так и будет.
Я совсем не использую requirejs т.к. это устаревшая технология, уже можно использовать es6 и es6 модули. Если проект новый и нет предрассудков и каких-то страхов, то зачем использовать устаревшие инструменты, когда есть современные?
0
Я не совсем согласен насчет «устаревшей» технологии, не так все плохо… Плюс он спокойно расширяется через модули и прикрутить туда компиляцию es6 никакого труда не составляет. А бонусы от компиляции в рантайме при этом остаются.
Я переформулирую вопрос — какие webpack предоставляет возможности для быстрой компиляции в режиме «изменил-сохранил-посмотрел в браузере», насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
Я переформулирую вопрос — какие webpack предоставляет возможности для быстрой компиляции в режиме «изменил-сохранил-посмотрел в браузере», насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
+1
У меня проект среднего размера, React + Flux + Webpack, при изменении файла автоматически пересобирается проект. Первая сборка забирает где-то 4.5 секунды, а все последующие 3.7. После сборки срабатывает autoreload. В принципе поменять что-то в коде и переключится в браузер — достаточно приемлимая скорость. Хотя я бы и сам не отказался бы от того, чтобы её ускорить.
0
У меня есть ноут, на котором сборка чего угодно, на чем угодно занимает 10 минут.
0
Вот я по этой самой причине (сборка дольше 3 секунд) и пришел к выводу, что я хочу все компилировать прямо в браузере, потому как пару раз ловил неприятные баги от того, что после переключения в браузер что-то успело собраться, а что-то нет.
0
>> сборка дольше 3 секунд
Вот по этой причине я и пришел к выводу, что прекомпиляция по частям и нормальные компьютеры спасут мир. Болтовня про скорость — чушь! Я таких разговоров ещё 10 лет назад наслушался. Прошло 10 лет, частота процессоров выросла на тысячи, появились SSD, а разговоры не изменились. Прямо маркетинговые лозунги — мой инструмент умеет быстро*.
На первом месте стоят возможности инструментов, скорость только на втором. Попробуйте SSD, может вам полегчает.
*, зато не имеет ещё 100500 нужных возможностей.
Вот по этой причине я и пришел к выводу, что прекомпиляция по частям и нормальные компьютеры спасут мир. Болтовня про скорость — чушь! Я таких разговоров ещё 10 лет назад наслушался. Прошло 10 лет, частота процессоров выросла на тысячи, появились SSD, а разговоры не изменились. Прямо маркетинговые лозунги — мой инструмент умеет быстро*.
На первом месте стоят возможности инструментов, скорость только на втором. Попробуйте SSD, может вам полегчает.
*, зато не имеет ещё 100500 нужных возможностей.
+1
Вы забываете, что размер проекта тоже растет. На проекте более тысячи файлов. И SSD есть почти у всех девелоперов, коих по последним подсчетам более ста человек. Вы так замечательно все додумываете, колкие фразочки пишете, а по существу ничего так толком и не сказали.
0
Не знаю откуда такие цифры, если использовать webpack.watch, то все ускоряется на порядок.
У меня проект, где react собирается из исходников (это 500кб кода), несколько входных точек и общие модули выделяются в отдельный файл, дев-сборка (без минификации) происходит за 3с. Сборка с минификацией и с дедупликацией за 12с. После этого watch отрабатывает за 200мс любое сохранение.
У меня проект, где react собирается из исходников (это 500кб кода), несколько входных точек и общие модули выделяются в отдельный файл, дев-сборка (без минификации) происходит за 3с. Сборка с минификацией и с дедупликацией за 12с. После этого watch отрабатывает за 200мс любое сохранение.
0
>>насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
У меня успевает, нареканий не было, проект большой и растет, но не вижу смысла обсуждать скорость webpack.
Любой инструмент упрется в скорость при росте проекта. Поэтому всегда использую вотчеры, которые сильно ускоряют процесс сборки. Считаю это оптимальным решением.
Как можно обсуждать скорость, не зная мощности компьютера, других инструментов, технологий и т.д. Абстрактные кони в вакууме и то нагляднее.
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
У меня успевает, нареканий не было, проект большой и растет, но не вижу смысла обсуждать скорость webpack.
Любой инструмент упрется в скорость при росте проекта. Поэтому всегда использую вотчеры, которые сильно ускоряют процесс сборки. Считаю это оптимальным решением.
Как можно обсуждать скорость, не зная мощности компьютера, других инструментов, технологий и т.д. Абстрактные кони в вакууме и то нагляднее.
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
0
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
Логично. Но пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели, а самое плохое — испытание на малом кол-ве файлов показательным не особо будет, так что прогнозировать, как оно заработает на большом проекте довольно трудно. Поэтому нужен чужой опыт.
0
>>пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели
Не знаю почему, но вам видней. Расскажите в чем проблема?
webpack.github.io/docs/comparison.html
Не знаю почему, но вам видней. Расскажите в чем проблема?
webpack.github.io/docs/comparison.html
0
На проекте используются requirejs плагины, а также не весь сайт собирается разом, он разбит на составные части, у которых собственный билд-процесс. Чтобы все нормально перевести на вебпак и протестировать придется потратить некоторое время, поэтому на данный момент я провожу анализ, стоит ли игра свеч.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы готовим React, Require и Backbone