Comments 34
Предлагаю еще посмотреть в сторону webpack, сам раньше всегда использовал requirejs, но оказалось что писать загрузку модулей с commonjs удобнее и красивее
мне CommonJS тоже нравится больше, однако мне почему-то жутко не нравится куча var-ов на каждую переменню. Одна var на все эти переменные тоже не сильно нравится… :) Вот import из ES6 было бы круче всего, как по мне.
можно взять 6to5, 6to5.org/docs/usage/modules/ там все это есть :)
а с кучей var тоже просто.
var React = require('react'),
Component = require('./component')
:)
а с кучей var тоже просто.
var React = require('react'),
Component = require('./component')
:)
Смотрите в сторону 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.
Спасибо, обязательно посмотрю.
Заголовок был многообещающим, а по факту не понятно как вы собираетесь передавать данные из моделей, будете ли использовать Бекбон вью и т.д.
нуб-вопрос про весь этот реакт/ангуляр/эмбер:
получается что вся страница собирается уже на клиенте, как обстоят дела с индексацией роботами и как увидят сайт пользователи, например ИЕ8 (да, приходится поддерживать)
получается что вся страница собирается уже на клиенте, как обстоят дела с индексацией роботами и как увидят сайт пользователи, например ИЕ8 (да, приходится поддерживать)
Если вы специально не позаботились, то роботы ничего не увидят.
Поддержки IE8 в Ангулар нет, в Реакте через полифилы и придется шаблоны прекомпилять. Про Эмбер не знаю. Если кратко, то очень плохая. Но на мой взгляд это закономерно.
Поддержки IE8 в Ангулар нет, в Реакте через полифилы и придется шаблоны прекомпилять. Про Эмбер не знаю. Если кратко, то очень плохая. Но на мой взгляд это закономерно.
Информация касательно индексации таких приложений яндексом.
По ссылке:
Другими словами: яндекс не умеет индексировать ajax (да и просто сгенерированные на клиенте) страницы.
Каждая индексируемая AJAX-страница должна иметь HTML-версию
Другими словами: яндекс не умеет индексировать ajax (да и просто сгенерированные на клиенте) страницы.
Получается что так. Логику подстановки данных в html шаблон придется реализовывать в двух местах, на клиенте для людей и сервере для Яндекса, Google и т.д.
Кстати, если ваша серверная часть написана на node.js, можно реализовать пререндеринг страниц на стороне сервера.
Кстати, если ваша серверная часть написана на node.js, можно реализовать пререндеринг страниц на стороне сервера.
Для Google уже давно не нужно делать пререндеринг, crawler понимает js.
Можно рендерить на бекенде страницы, а потом поверх запускать фронтэнд приложение. По крайней мере так на backbone делаем
prerender.io в помощь
>>Всё и сразу пока не работает.
Убило наповал. Зачем статья?
Зачем тащить было в проект Backbone и requirejs? Обоснование отсутствует. Вы не понимаете Flux, поэтому притащили в проект Backbone? Или в нем есть необходимость, потому что Flux не устраивает этим и этим?
React + Flux + 6to5 + webpack избавляет от прошлого века requirejs.
Фига себе прозрачность в контроллерах Backbone находятся компоненты React.
Убило наповал. Зачем статья?
Зачем тащить было в проект Backbone и requirejs? Обоснование отсутствует. Вы не понимаете Flux, поэтому притащили в проект Backbone? Или в нем есть необходимость, потому что Flux не устраивает этим и этим?
React + Flux + 6to5 + webpack избавляет от прошлого века requirejs.
Фига себе прозрачность в контроллерах Backbone находятся компоненты React.
А насколько у webpack хорошо с компиляцией в рантайме? Я вот поставил requirejs с jsx плагином и могу все на живую компилировать, никаких watcher'ов и т.п., webpack же, насколько я понимаю, заставит меня через свой сервер ходить для этого.
Если вы не хотите использовать watcher-ы, то это ваши проблемы. Можете не использовать.
Можно компилировать наживую, через watcher-ы, через watcher wabpack или запускать webpack для сборки. Как настроите так и будет.
Я совсем не использую requirejs т.к. это устаревшая технология, уже можно использовать es6 и es6 модули. Если проект новый и нет предрассудков и каких-то страхов, то зачем использовать устаревшие инструменты, когда есть современные?
Можно компилировать наживую, через watcher-ы, через watcher wabpack или запускать webpack для сборки. Как настроите так и будет.
Я совсем не использую requirejs т.к. это устаревшая технология, уже можно использовать es6 и es6 модули. Если проект новый и нет предрассудков и каких-то страхов, то зачем использовать устаревшие инструменты, когда есть современные?
Я не совсем согласен насчет «устаревшей» технологии, не так все плохо… Плюс он спокойно расширяется через модули и прикрутить туда компиляцию es6 никакого труда не составляет. А бонусы от компиляции в рантайме при этом остаются.
Я переформулирую вопрос — какие webpack предоставляет возможности для быстрой компиляции в режиме «изменил-сохранил-посмотрел в браузере», насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
Я переформулирую вопрос — какие webpack предоставляет возможности для быстрой компиляции в режиме «изменил-сохранил-посмотрел в браузере», насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
У меня проект среднего размера, React + Flux + Webpack, при изменении файла автоматически пересобирается проект. Первая сборка забирает где-то 4.5 секунды, а все последующие 3.7. После сборки срабатывает autoreload. В принципе поменять что-то в коде и переключится в браузер — достаточно приемлимая скорость. Хотя я бы и сам не отказался бы от того, чтобы её ускорить.
У меня есть ноут, на котором сборка чего угодно, на чем угодно занимает 10 минут.
Вот я по этой самой причине (сборка дольше 3 секунд) и пришел к выводу, что я хочу все компилировать прямо в браузере, потому как пару раз ловил неприятные баги от того, что после переключения в браузер что-то успело собраться, а что-то нет.
>> сборка дольше 3 секунд
Вот по этой причине я и пришел к выводу, что прекомпиляция по частям и нормальные компьютеры спасут мир. Болтовня про скорость — чушь! Я таких разговоров ещё 10 лет назад наслушался. Прошло 10 лет, частота процессоров выросла на тысячи, появились SSD, а разговоры не изменились. Прямо маркетинговые лозунги — мой инструмент умеет быстро*.
На первом месте стоят возможности инструментов, скорость только на втором. Попробуйте SSD, может вам полегчает.
*, зато не имеет ещё 100500 нужных возможностей.
Вот по этой причине я и пришел к выводу, что прекомпиляция по частям и нормальные компьютеры спасут мир. Болтовня про скорость — чушь! Я таких разговоров ещё 10 лет назад наслушался. Прошло 10 лет, частота процессоров выросла на тысячи, появились SSD, а разговоры не изменились. Прямо маркетинговые лозунги — мой инструмент умеет быстро*.
На первом месте стоят возможности инструментов, скорость только на втором. Попробуйте SSD, может вам полегчает.
*, зато не имеет ещё 100500 нужных возможностей.
Вы забываете, что размер проекта тоже растет. На проекте более тысячи файлов. И SSD есть почти у всех девелоперов, коих по последним подсчетам более ста человек. Вы так замечательно все додумываете, колкие фразочки пишете, а по существу ничего так толком и не сказали.
Что я должен сказать по существу о вашем абстрактном проекте, вашей абстрактной сборке на вашем абстрактном компьютере?
Например, вы могли бы рассказать о статистике на Вашем не-абстрактном проекте, Вашей не-абстрактной сборке на Вашем не-абстрактном компьютере. Например, как это сделал standy.
Не знаю откуда такие цифры, если использовать webpack.watch, то все ускоряется на порядок.
У меня проект, где react собирается из исходников (это 500кб кода), несколько входных точек и общие модули выделяются в отдельный файл, дев-сборка (без минификации) происходит за 3с. Сборка с минификацией и с дедупликацией за 12с. После этого watch отрабатывает за 200мс любое сохранение.
У меня проект, где react собирается из исходников (это 500кб кода), несколько входных точек и общие модули выделяются в отдельный файл, дев-сборка (без минификации) происходит за 3с. Сборка с минификацией и с дедупликацией за 12с. После этого watch отрабатывает за 200мс любое сохранение.
>>насколько быстро он успевает все подхватить и перестроить для средних размеров проекта? Для меня важно, чтобы инструмент успевал отработать за то время, пока я переключаюсь из редактора в браузер и пока обновляется страница.
У меня успевает, нареканий не было, проект большой и растет, но не вижу смысла обсуждать скорость webpack.
Любой инструмент упрется в скорость при росте проекта. Поэтому всегда использую вотчеры, которые сильно ускоряют процесс сборки. Считаю это оптимальным решением.
Как можно обсуждать скорость, не зная мощности компьютера, других инструментов, технологий и т.д. Абстрактные кони в вакууме и то нагляднее.
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
У меня успевает, нареканий не было, проект большой и растет, но не вижу смысла обсуждать скорость webpack.
Любой инструмент упрется в скорость при росте проекта. Поэтому всегда использую вотчеры, которые сильно ускоряют процесс сборки. Считаю это оптимальным решением.
Как можно обсуждать скорость, не зная мощности компьютера, других инструментов, технологий и т.д. Абстрактные кони в вакууме и то нагляднее.
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
Вы же понимаете, что пока не попробуете сами ничего не узнаете наверняка?!
Логично. Но пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели, а самое плохое — испытание на малом кол-ве файлов показательным не особо будет, так что прогнозировать, как оно заработает на большом проекте довольно трудно. Поэтому нужен чужой опыт.
>>пока я буду переводить основной проект с тысячами файлов на webpack пройдут недели
Не знаю почему, но вам видней. Расскажите в чем проблема?
webpack.github.io/docs/comparison.html
Не знаю почему, но вам видней. Расскажите в чем проблема?
webpack.github.io/docs/comparison.html
На проекте используются requirejs плагины, а также не весь сайт собирается разом, он разбит на составные части, у которых собственный билд-процесс. Чтобы все нормально перевести на вебпак и протестировать придется потратить некоторое время, поэтому на данный момент я провожу анализ, стоит ли игра свеч.
Sign up to leave a comment.
Как мы готовим React, Require и Backbone