Comments 135
В отличии от готового boilerplate шаблона для клиентской сборки, create-react-app это отдельный пакет. Это значит что его легко интегрировать, легко обновить в будущем. Представте что у вас уже есть проект с кучей зависимостей, если вы хотите прикрутить к нему какой-то шаблон, то вам нужно вручную его смержить. К тому же create-react-app гораздо качественее большинства других шаблонов.
Именно. Всем приходится со временем снимать подгузники.
Что значит "хочется"?
Если вы профессионал и знаете, какие проблемы решают css-modules, например, то у вас не будет проблем с их настройкой.
Если вы просто где-то слышали, что это круто, то необязательно кидаться внедрять это себе в проект непонятно для чего.
А если все-таки очень хочется, то будьте готовы к трудностям в изучении, ведь это технологии advanced-уровня, не нужные на каждой веб-страничке
Как я понимаю — жизнь и так сложная штука. Так зачем усложнять её, пытаясь искать индивидуальный подход там, где можно делать всё под одну гребёнку. Вот например берём ангуляр и всегда делаем интерфейс ангуляром. Думать начинаем когда возникают проблемы — не раньше.
Вот и тут — делаем реактом, потому что умеем. Так быстрее получится сделать, только надо выработать подход — как собирать код с реактом.
Просто это не обязательно когда понятно как это работает. Просто это ещё и когда нет необходимости разбираться как оно работает.
К сожалению, на JQuery особо проще не будет, SPA писать сложнее, чем приложение на пост-бэках. Показывать модальные окна, валидировать ввод пользователя, генерировать HTML по из шаблонов, с JQuery тоже не тривиальная задача. Но в отличии от React или подобных фреймворков, JQuery решение хуже маштабируется, когда проект становится больше. Проще не значит просто :)
ИМХО Проблема современного фроент-мира — все пытаются найти готовое решение вместо того что бы использовать вещи которые уже есть в нативном js и написать лишних 5-10 строчек кода
А самое странное во всём это то, что при таком армии жаждущих найти готовое решение, все готовые решения не готовы. Где-то нет вменяемого кеширования, где-то недостаточно гибкости, где-то целая куча избыточных зависимостей, ну и т.д… Апогеем стала невозможность обычного подключения библиотеки в обход webpack-а.
Точно также, если мне нужно сделать простенькое одностраничное приложение в мире руби, я не буду разворачивать рельсы, мне будет достаточно синатры, либо вообще какого-нибудь грейпа если речь идет об API.
Конечно, я не пронтендер, но я не понимаю почему в 2016-м нельзя просто решить поставленную задачу при помощи того же jQuery который может дергать те же данные в json. Конечный пользователь разницы точно не заметит, а разработчик средней руки не будет ломать голову над тем как обуздать +1 новый фреймворк.
В бэкенде конечно все значительно проще как по количеству решений так и по их инфраструктуре, стабильности релизов и ожиданиям. Во фронтенде я действительно чувствую что попал в какой-то футуристический мегаполис где все светится и сверкает неоновыми иероглифами и я могу ориентироваться только на ощупь не понимая куда иду понимая только частично надписи.
Да, это можно выразить одним словом — там застой! ;-)
phoenixweiss > Во фронтенде я действительно чувствую что попал в какой-то футуристический мегаполис где все светится и сверкает неоновыми иероглифами и я могу ориентироваться только на ощупь не понимая куда иду понимая только частично надписи.
Да, и это можно выразить одним словом — тут фан. ;-)
phoenixweiss > но я не понимаю почему в 2016-м нельзя просто решить поставленную задачу при помощи того же jQuery который может дергать те же данные в json.
jQuery не запрещён в 2016 году. Можно и только на нём.
Но дело в том, что вам придётся писать расширяемое большое приложение (или искать работу где это придётся делать) — вот поэтому надо начинать с этого всего, что описано в статье, чтобы дальше… дальше… дальше писать код. Современный код. ;-)
Имхо, конечно, имхо.
Да, и это можно выразить одним словом — тут фан. ;-)
Это можно выразить одним словом — тут анархия!
(Представим себе африканскую страну, где повсюду орудуют банды, делают что хотят — грабят, убивают. Принцип — живи здесь и сейчас, не строй долгосрочных планов, никаких заводов, науки; поехал в соседнюю деревню ограбил жителей, ищешь другую деревню и т.д.)
Да, это можно выразить одним словом — там застой! ;-)
Это можно выразить одним словом — тут порядок!
(Представим себе современных мегаполис, например, Нью-йорк. Здесь царит закон и порядок. Существую правила, есть те, кто за ними следят. Жизнь размерена — люди могут спокойно заводить детей, строить планы на будущее, нет боязни, что тебя убьют при выходе из дома. В супермаркетах есть еда. Есть постоянная работа и т.д.)
Имхо, конечно, имхо.
Вряд ли. Стандартов хватает. Даже слишком! :-)
gen_dalf > (Представим себе африканскую страну, где повсюду орудуют банды, делают что хотят — грабят, убивают. Принцип — живи здесь и сейчас, не строй долгосрочных планов, никаких заводов, науки; поехал в соседнюю деревню ограбил жителей, ищешь другую деревню и т.д.)
Представим себе современный город, типа Нью-Йорк — где каждую неделю открываются по несколько новых кафе, каждый месяц по несколько новых ресторанов и всю ночь можно тусоваться!
gen_dalf > Это можно выразить одним словом — тут порядок!… Представим себе современных мегаполис, например, Нью-йорк. Здесь царит закон и порядок…
Стоп! — Нью-Йорк я уже представил себе совершенно иначе! ;-)
В свое время приходилось каким-то чудом спасать проекты, написанные на модном 10 лет назад «парсере», который очень быстро и модно взлетел но потом также быстро выгорел.
Все кто смеялся над «этим вашим PHP который вот-вот умрет», в итоге оказались не правы. Прошло 10 лет, парсера нет а PHP до сих пор жив.
Мы в свое время перешли с PHP на Ruby не только из-за легкого и читаемого синтаксиса но также из-за более-менее прозрачного графика релизов основных фреймворков и очень хорошей поддержки сообщества.
Если говорить про те же рельсы — мы сейчас спокойно обслуживаем проекты, написанные в 2012-13 году, и прекрасно представляем что нужно чтобы при необходимости актуализировать их с наименьшими трудозатратами. У Рельсов цикл примерно 2-3 года, для сравнения в мире современного фронтенда значимые изменения происходят значительно чаще, и во многих «модных» решениях через полгода-год ломается обратная совместимость и разработчик оказывается в ситуации когда необходимо принять решение что делать дальше и чаще всего вынужден переписывать решение на более новый технологический стек. Стоит ли говорить что заказчику далеко не всегда можно адекватно объяснить почему каждый год необходимо переписывать его приложение чтобы оно продолжало быть поддерживаемым и могло развиваться.
В этой ветке также очень хорошо кроме меня прокомментировали про анархию / порядок. Чем мне нравится Ruby / Rails? В первую очередь — порядком. Да, конечно это субъективно и справедливо можно заметить о том что этот стек также имеет некоторые проблемы (с теми же turbolinks которые разделились на легаси-ветку classic и основную ветку и многое другое), но я уверен что в одночасье «завтра» большое приложение, написанное на рельсах «вдруг» не превратится в тыкву как в сказке про Золушку. В худшем случае придется переписать несколько тестов и повычищать в коде депрецированные методы. Но мы на своей памяти спокойно мигрировались с 3-х рельсов на 4-е, а сейчас также спокойно значимые проекты переводим на пятые, параллельно осознавая то что написанные на четверке еще пару лет проживут спокойно.
Вряд ли год — это слишком. Обычно через три года и более. Это уже терпимо.
phoenixweiss > В свое время приходилось каким-то чудом спасать проекты, написанные на модном 10 лет назад «парсере», который очень быстро и модно взлетел но потом также быстро выгорел.
10 лет выгорал — это нормально. ;-)
phoenixweiss > У Рельсов цикл примерно 2-3 года, для сравнения в мире современного фронтенда значимые изменения происходят значительно чаще, и во многих «модных» решениях через полгода-год ломается обратная совместимость и разработчик оказывается в ситуации когда необходимо принять решение что делать дальше и чаще всего вынужден переписывать решение на более новый технологический стек.
Ломка обратной совместимости не связано с «модностью».
У Swift это заложено изначально.
А бают, что Piton, старше Java на 4 года, но поломал обратную бинарную совместимость недавно, в версии Piton-3
phoenixweiss > а сейчас также спокойно значимые проекты переводим на пятые, параллельно осознавая то что написанные на четверке еще пару лет проживут спокойно.
Так вы нормально двигаетесь то, шагами и с перспективой на пару(!) лет, а не застряли в версии 2, к примеру этих Ruby / Rails. ;-)
P.S. И я извиняюсь, но обилие смайлов на все ваши комментарии и «Piton» как-то подсознательно заставляют воспринимать комментарии несерьезно. Так что я думаю в дальнейшем беседу поддерживать малополезно. Ваша позиция понятна.
Да, там больше фана. Я просто сбежал из мира Java. Там скука и тлен.
phoenixweiss > но обилие смайлов на все ваши комментарии и «Piton» как-то подсознательно заставляют воспринимать комментарии несерьезно.
Не обращайте внимание. Да я и на работу в джинсах прихожу. ;-)
Вот у меня есть друг — он начальник отдела разработки в банке. Солидный человек. В галстуке. Там базы данных. SQL. Он уже про базы и говорить не хочет. — Так и говорит — ни слова о базах — давай о поэзии. ;-)
А другой знакомый (практика SQL не один год) мне говорит, что молодёжь от скуки в мире SQL придумывает всякие несуразности (так он считает) — ну чем то им всё же хочется там развлекаться. ;-)
Я же просто сбежал в мир Javascript. Пока… хоть тут ещё есть жизнь. ;-)
Остальной мир всё больше закоболяется (от слово Кобол). ;-)
Имхо, конечно, имхо.
Ответ: Можна. EmberJs.
How to:
1) npm install -g ember-cli
2) ember new my-new-app
3) ember server
Под катом уже RestAdapter, JsonAdaper. Удобная EmberData (ActiveRecord) для моделей, Controller, Router и тд. Минимум усилий для нормального старта + документация на уровне
но я не хочу сервер на js.
Было бы удобно взаимодействие с клиентом по rest/soap/etc… без жесткой зависимости клиент-серверной архитектуры.
В принципе, выскажу крамольную мысль, что по факту Rich UI (Недавняя статья на хабре) удобнее чем полноценный MVC фреймворк на клиенте.
Как мне видится нормальная разработка:
Клиенту сгружаются сырые данные, js фреймворк их превращает в модели, готовая GUI компонета их отображает. Нам остается реализовать обработчики событий, фильтры и т.п.
Пара вопросов к аудитории:
- Как вы подключаете react-router? Библиотека client-side. Берём bower. Смотрим что подключать. Гхм. Кандидатов нет. Внимательно шерстим все файлы — не понятно. В readme указано, что нужно просто прописать import в коде. И оно заработает. Оо, чего? Ок, в readme указано, что вот по ссылке доступен уже готовый umd-файл, качайте. Чего? Оо. Качать файл с сети и руками его заталкивать в проект? Вроде бы 2016. Брр. Такс. Идея. А может глянем в npm? Смотрим в npm, о, а тут есть вариант для es6-модулей. Открываем файлы и видим, что там иерарические import-ы. В то время как файловая структура в 1 уровень. Откуда они берут эти файлы? ага, вот рядом лежит webpack. Они что на полном серьёзе мне предлагают её собирать? Гхм. О, вот есть готовый собранный umd-вариант. По старинке руками прописываем путь к нему в сборочный скрипт. ЧЯДНТ?
- Сборочный скрипт. Хочу чтобы он автоматически копировал скрипты всех bower-зависимостей куда я укажу. Ищу gulp-плагин. Нахожу. Подключаю — опа, а он подключает не то. Смотрим почему. Ага, у ряда библиотек криво прописаны настройки пакета. Городим костыли-исключения. Ок. Смотрим. 2 MiB. О боже, откуда столько? А ну да, это не минифицированные версии
слоновсовременных библиотек. Хочу минифицированные версии. Где взять? Ну вот же они рядом с файлами лежат почти во всех плагинах. Ок. Где плагин, который их поищет и поправит пути? Гхм. Нет такого. Есть один кривой, который заменяет саму bower-обёртку, не годится. Что делать? Ок, пишем костыли. Ух, а это что такое? Это наш любимый ReactNative.js. Почему camelCase? Видимо авторам так нравится. ВСЕ остальные библиотеки kebab-case. Ок, подключаем lodash, пишем костыль с _.kebabCase. Хм. Я хотел как-то попростенькому исопльзуя достижения js-человечества подключить скрипты из репозитория. А что получилось? Куча каких-то костылей.
Привёл 2 примера. Но по сути куда бы я не полез, везде, везде вынужден что-то городить. Т.к. то, что есть или не работает, или работает в пол-силы. Или вообще кривое до нельзя. Самыми странными мне показались бубны с цепочкой всяких gulp-browserify — gulp-babelify — babel — browserfy — babelify — watchify и прочим. От них всех крыша едет. Одно очевиднее другого. В итоге опять костыли-костыли-костыли.
Хотя казалось бы, столько хайпа. Светлое будущее наступило. А на деле вот.
Чудесный стек-трейс. Ни бита полезной информации. Он зашит в message. Содержит пути на строки кода файла без учёта sourcemap. Прямо мечта. Особенно если это bundle на десяток тыщ строк. В итоге оборачиваю точку входа setTimeout-ом (снова костыль) и получаю нормальные стектрейсы.
- И как это должно работать? Вот вы написали "import ...". Приведите всю цепочку, весь механизм.
- И зачем он мне? С его возможностями я примерно знаком по скринкасту (многочасовому). Совершенно избыточный инструмент для моих текущих нужд. Мне даже бандлы не нужны.
Вопросы?
Вы сделали очень сильное предположение о том, что я использую: webpack. И что моя конфигурация webpack-а съест это всё. А я его не использую. А теперь следите за руками:
- мы пишем
import { Router, Route, Link } from 'react-router'. - браузер не знает такого токена. Беда. Ок. Подключил полифил
systemjs, подключилbabelи прочее и настроил сборку - теперь браузер ругается на то, что по адресу
./react-routerничего нет. - ок, нужно при сборке его туда поместить, либо же указать в
pathнужный путь - ладно, но где взять путь? хм, смотрим в
bower.json. Беда. Всё разобрано, вхлам, причём без зависимостей. Беда. - ладно ищем глазами — готового файла нет
- ладно ставим из npm (уже костыли пошли), смотрим
package.json, та же самая проблема. Только теперь зависимости разложены поnode_modules(а их пути к тому же могут меняться) - ищем глазами и наконец находим по необычному адресу готовый js.
- подключаем к механизму сборки. работает.
- какого чёрта? это единственная из библиотек что мне на текущий момент попадались, которая была настолько лихой.
Предлагаете пользователям качать все скрипты
- В данный момент у меня мобильное приложение на cordova. вот скажите, на кой чёрт мне бандлы?
- Даже безотносительно этого, в dev-режиме с отдельными файлами работать проще, а сами эти файлы собираются быстрее. Особенно учитывая какого веса нынче библиотеки. Да и sourcemap увы не идеальны. Несмотря на многолетний стаж.
- http2 тоже реален
В таком случае тоже есть решение — System.js.
Да-да, смотрим выше.
но вы же, вроде, сами хотели, чтобы компьютер сам резолвил все зависимости и позволял вам пользоваться всеми достижениями js-человечества.
Таки не всеми, всеми слишком жирно будет. У webpack-а другое предназначение. Это не инструмент для разрешения зависимостей. Это лишь одна из его возможностей. Которая всё равно разбивается о суровую реальность кривых .json файлов. Помнится в скринкасте был чудесный пример, как оно мановением руки может затащить в бандл десятки ненужных файлов.
webpack поднимает для этого dev-сервер.
Кстати ещё и это. Даёшь больше энтропии на ровном месте. Каждый 1-ый npm-пакет обязан тащить с собой json-сервер. И желательно на expressjs, иначе не кошерно будет.
не прописывали?
Нет, конечно. Оно не сработает, т.к. не пробьётся в node_modules, его просто нет в сборке. И не должно быть. Я не потащу в cordova-приложение эту помойку на 70+ MiB. И не потащу на web-production тоже.
Но вы меня заинтриговали. Оно будет спамить сервер насилуя node_module/*/project.json-ы? В самом деле? о_О. Это новое слово во фронтенде :) Я думал хуже не куда, видимо я ошибался.
Вы меня заинтриговали.
- Вы говорите, что webpack позволит вытащить из lodash только необходимое. Звучит вкусно. А как? Автоматически он это сделать скорее всего не сможет, просто исходя из того, что в package.json прописан уже собранный скрипт (17 тысяч строк). Нужно подключать окольными путями? К чему будет сведён конфиг? Перефразирую вопрос: насколько сложно это будет растачивать, чтобы оно правда так работало и либа функционировала?
- Разруливание зависимостей звучит приятно. Но возьмём скажем knockoutjs. На npm его нет. Но есть в bower. Есть два готовых файла, один из которых прописан в main. В dev-разработке однозначно нужен второй (.debug), т.к. без него debug сильно затруднён. Вопрос — во что выльется настройка такого поведения webpack-а?
- Ряд библиотек собираются таким образом, что часть кодовой базы срезается для production-а. Как это используется webpack-ом?
- Подключил я, скажем, какой-нибудь хороший control. Скажем select2. Помимо самого select2 мне нужна локализация. Причём не вся (там огого сколько всего). Как это будет реализовано в webpack-конфиге?
Сдаётся мне, что автоматическое выруливание зависимостей сыграет свою роль только в react-router-е. Да и то, вместо подлючения готого собранного umd файла будет подключены 3-4 десятка мелких, каждый из которых будет обёрнут в webpack обёртку. Кстати говоря вопрос — а сможет ли он сократить эти 4 десятка в один десяток, проанализировав всю кодовую базу на предмет их использования? Вроде что-то такое было заявлено.
Но, возможно, когда-нибудь спецификации пакетов будут столь хороши, что можно будет сделать это всё без шуму и пыли. Или будущее уже наступило?
import array from 'lodash/array';
2) Читаем документацию: https://webpack.github.io/docs/usage-with-bower.html
Для дев конфига можно прописать алиас на не минифицированный файл.
3) Если библиотека правильная то все что для продакшина не нужно, срезается установкой переменой окружения `NODE_ENV=production`, собственно строка запуска будет такой: `NODE_ENV=production webpack ...`
4) В вебпак кофиге это ни как реализовывать не нужно, просто нужно подключить только ту локализацию которая нужна прямо в коде приложения
Мои требования полностью покрываются вебпаком.
Я не использую вебпак, потому что не хочу.
Веб-технологии плохие, они не могут сделать как мне надо.
Вы не видите тут противоречий?
Вы не видите тут противоречий?
Угу, достаточно всего одного слова: избыточный. Он делает слишком много лишнего и совсем не так, как мне это нужно. Этот инструмент в целом мне понравился, и я полагаю, что буду в будущем его применять для очень больших модульных проектов. Т.к. главная его вкусная вещь это умение хитрым образом строить бандлы по всем хитросплетениям зависимостей.
Но вот ездить на K700 по песочнице — увольте.
Ну страдайте тогда, или пишите свой вебпак, не избыточный лично для вас.
И никому кроме вас не нужный.
Уже готово. 50-70 строк. Быстро и то, что нужно. По поводу того, что кроме меня оно никому не нужно: вы полагаете, что это должно меня как-то расстраивать? Удивительно.
Нет, почему же.
Это вполне нормально, если это будет использоваться только в ваших личных проектах.
А вот если это будет использоваться в работе компании, то вы сразу получаете ворох проблем.
- Поддерживать этот код и и обновлять будете лично вы. Когда вы этого делать не будете, он будет устаревать. То есть почти всё время.
- Другим разработчикам, которые приходят на проект и ваше поделие видят впервые, объяснять принципы его работы тоже будете лично вы. Каждый раз. Они вас за это будут очень любить.
- Вы, конечно, можете написать документацию и периодически её обновлять. Теперь вам нужно поддерживать не только код, но ещё и документацию
- Тестировать тоже будете лично вы. Тесты, очевидно, вам тоже нужно поддерживать и обновлять.
Если вас это всё устраивает или вы ещё на светлой стороне программирования, то я очень рад за вас и ваш энтузиазм.
Как вы всё хитро обыграли.
- а почему только только я? все умерли?
- другие разработчики, помимо этих строк, ещё и всю остальную кодовую базу разделяют
- какая документация? примитивный .pipe код для gulp-а, с парой комментариев в узких местах. я напомню, решение простое, в отличии от webpack-а (вы откройте любой webpack-бандл… хуже только бинарники)
- тестировать будем все, или все умерли?
Тёмная сторона, светлая сторона. Занесло вас. А кодовую базу вы тоже по кубикам собираете? Скажем, если вам потребовалась кнопочка, а готовой либы не нашлось, вы будете подключать dojo.js? Там она есть, честно-честно.
а почему только только я? все умерли?
кроме меня оно никому не нужно
Поэтому
другие разработчики, помимо этих строк, ещё и всю остальную кодовую базу разделяют
Другая кодовая база никуда деться не может, её придётся разделять в любом случае. А ваш эту задачу усложняет самим своим существованием. Его вполне можно из неё исключить и облегчить разработчикам задачу. То есть ускорить вникание в проект и работу над ним. То есть удешевить разработку. Понимаете?
какая документация?
примитивный .pipe код для gulp-а, с парой комментариев в узких местах
Вот эта самая. Её надо читать.
тестировать будем все, или все умерли?
Что лишний раз увеличивает сложность проекта
Скажем, если вам потребовалась кнопочка, а готовой либы не нашлось, вы будете подключать dojo.js? Там она есть, честно-честно.
Тогда, к сожалению, кнопочку придётся написать. И это плохо.
В первую очередь это касается SPA и cordova. Приложение из одного файла будет грузиться быстрее, чем из сотни мелких файлов.
> Даже безотносительно этого, в dev-режиме с отдельными файлами работать проще, а сами эти файлы собираются быстрее.
WebPack заменяет только те части, которые изменились.
> http2 тоже реален
HTTP2 никак не решает проблему иерархических зависимостей.
В первую очередь это касается SPA и cordova. Приложение из одного файла будет грузиться быстрее, чем из сотни мелких файлов.
Один или несколько файлов с ssd-диска будут грузиться и правда немного быстрее. Но совсем не радикально. К тому же для production-сборки можно (нужно) добавить строку с gulp-concat. Хорошо когда есть выбор.
WebPack заменяет только те части, которые изменились.
Гхм, а как вы себе представляете переписывание файла-бандла не целиком? Это же обычный текстовый файл. Прошу пояснить, что вы имеете ввиду. Или вы имеете ввиду то, что остальные файлы берутся из кеша? Ну дык а как иначе, иначе оно будет просто люто тормозить.
HTTP2 никак не решает проблему иерархических зависимостей.
А вот тут я с вами соглашусь. Это больше спрайтов касается. Там иерархии нет.
https://nodejs.org/api/fs.html#fs_fs_createreadstream_path_options
Если вас интересует, как работает файловая система или как ОС позволяет работать с файлами, то можете почитать, иначе, просто поверьте на слово. А лучше запустите webpack и все увидите сами.
Webpack работает и работает все лучше и лучше, и вы не привели ни одного аргумента, чтобы использовать что-то самописное, кроме фатального недостатка. Так что, советую оглянуться.
Браузеры ощутимо тупят, когда число скриптов исчисляется сотнями, поэтому эффективней склеить в один бандл. Обычным конкатом с поддержкой сорсмапов.
У меня вопрос по поводу вебпаков и system js. Вот есть бэкенд на джаве и фронтенд на ангуляре. node_modules к этому фронтенду весят 90 мегабайт и там файлов очень много. Деплой для разработчика — травматичная вещь. Допустим раз мы задеплоили node_modules, потом их можно не копировать, но надо же приверить на изменения папку и это тоже время занимает.
Хочется деплоить не весь node_modules, а только файлы, которые реально нужны. Можно как-то этого достичь?
Деплой и развёртывание это разве не синонимы?
Ок, хорошо. Можно сборку как-то ускорить, убрав из node_modules всё, что не нужно для работы приложения? Чтобы он не 90 мегабайт весил?
Вот в node_modules в каждом модуле, помимо библиотеки есть тесты, документация и всё такое. Можно как-то оставить только нужный код?
Ещё каждый модуль тянет свои зависимости. Можно как-то оставить только по одной версии каждой зависимости?
Не могли бы вы пояснить на примере или суть? Про npm link выдаёт вот это, где речь идёт о различных symlink-ах.
Я похоже не правильно вас понял. Я думал, что вы говорите, что есть простая возможность упаковки node_modules для production. Т.е., включая все стили, изображения, прочие необходимые файлы, но исключая все примеры, документацию и многое многое другое. Для этого недостаточно информации в project.json. Если же речь шла именно про webpack и подключённое через него в коде или конфиге, тогда ясно.
На сервере сборки наверное ничем не помешает. А на локальной машине разработчика приложение долго полностью перезапускать.
Сейчас можно сначала собрать фронтенд, а потом собрать джаву мавеном и мавен просто возьмёт весь фронтенд, включая node_modules и скопирует в директорию сборки.
Если node_modules уменьшить — время сборки меньше будет из-за того, что копировать меньше.
Или надо как-то мавеном собирать уже на месте, но как я пока не решил.
Типа того. Долго перезапускается. Потому что для чистого перезапуска нужно node_modules копировать.
Чистый перезапуск подразумевает, что мы перед этим всё сотрём. Может не стоит чистый перезапуск часто делать, это да. В данный момент у node_modules всегда проверяется на актуальность, если хоть какой-нибудь джаваскрипт модифицировать. Сборщик должен же проверить, что изменений нету по сравнению с предыдущим запуском.
Дело не в том, что модули перекачиваются каждый раз. Дело в том, что сначала собирается фронтенд, в том числе node_modules, а потом его надо скопировать в директорию, где джава будет искать статические файлы.
Не надо деплоить node_modules.
Надо
- Выкачать правки через
git checkout masterиgit pull - Обновить зависимости через
npm iиnpm update - Собрать
node_modulesв минифицированный бандл - Выкатить этот бандл.
Проблема в том, что это не мгновенная операция и именно для её ускорения фейсбук выпустил свой Yarn.
Меня больше всего интересуте третий шаг. Сборка в минифицированный бандл. Сейчас на фронтенде зависимости подтягиваются через system.js.Если собирать в бандл, нужно от него отказатся? И чем собирать? Вебпаком?
Да чем угодно. Хоть грантом, хоть вебпаком. Мне последний нравится больше.
Гранту, насколько я помню нужно отдать список файлов для бандла. Можно как-то построить его автоматически? Или надо руками его поддерживать?
Вот чего не знаю того не знаю.
Вы сами руками список поддерживаете, я правильно понимаю?
Да, он не сильно меняется, поэтому это не проблема.
В gulp можно сделать как-то вот так. Для части библиотек потребуется вести список вручную. Остальные же подгрузятся через .json из пакетов.
Скажите пожалуйста, везде читаю про "глобальную" сборку, а как выглядит разбиение и сборка по страницам. Я сейчас имею ввиду не классические страницы, а всё ещё single page app. Просто его нужно же тоже разбивать на страницы (view), таким образом, что если пользователь заходит изначально в один view, то ресурсы для других не загружаются, переходит пользователь в другое вью, мы просто подгружаем ресурсы для него, и так далее, ну вы меня понимаете. Так вот, например, react-router: есть у нас компоненты UserList и UserEditor под разные маршруты. У каждой страницы свои зависимости. Но есть и глобальные зависимости для приложения, jquery.js например. И теперь когда собираем приложение:
- будут ли ресурсы разделены по бандлам, например
global.js,user-list.jsиuser-editor.js? - будут ли бандлы грузиться в зависимости от маршрута?
- что будет происходить с компонентами которые будут и в
UserList, и вUserEditorиспользованы, но не в глобальных зависимостях? - система сборки как-то перепишет мой код, что бы грузить сначала нужный бандл, вместо десятка скриптов для страницы?
Может знаете пример небольшого приложение, где будет разделение на страницы и соответственно сборка тоже по страницам. Не обязательно реакт, что нибудь, интересен просто подход. Или просто статью, где именно акцент на view dependencies.
Есть мнение, что лучше загрузить сразу все скрипты и положить их в кеш, зато потом переключать страницы мгновенно, чем быстро показать первую страницу, а потом тупить над каждой следующей.
А истина где-то посередине. Проекты, их размеры, модульность, требования к проекту… всё это бывает очень по-разному. Webpack это такой монстр, которому это под силу. Мне кажется, именно для этого он и задумывался, т.к. эта часть его арсенала наиболее выдающаяся. Правда, похоже, современный frontend любит большие и сложные инструменты навязывать как для простых задач, так и для сложных.
что будет происходить с компонентами которые будут и в UserList, и в UserEditor использованы, но не в глобальных зависимостях?
Отличный вопрос. Я его пока для себя так и не закрыл. Пока что все большие общие зависимости выношу в отдельный бандл (подключается всегда). А зависимости поменьше включаются в каждый бандл, где они используются. Мирюсь с небольшим оверхедом по размеру.
Может знаете пример небольшого приложение, где будет разделение на страницы и соответственно сборка тоже по страницам
https://github.com/davezuko/react-redux-starter-kit
Здесь шаблон spa с парой преднастроенных страниц. И да, динамическая загрузка бандлов для них.
Привёл 2 примера. Но по сути куда бы я не полез, везде, везде вынужден что-то городить. Т.к. то, что есть или не работает, или работает в пол-силы.
Если использовать правильные инструменты и читать документацию, то никаких проблем с реактом и его экосистемой не возникнет.
В итоге оборачиваю точку входа setTimeout-ом (снова костыль) и получаю нормальные стектрейсы.
А не могли бы вы чуть подробнее написать об этом? :)
SystemJS.import('app.js');- в
app.jsесть ошибка, скажем, вызов несуществующего метода или что-нибудь ещё - ошибка валится в консоль, скриншот я привёл. Основной стек-трейс абсолютно бесполезен. А настоящий вшит в
message. Однако, в нём ссылки на транспайлернутый файл и строку в нём. Т.е. ткнув по ней в консоли вы попадёте не в оригинальный файл, а итоговый. А он может быть весьма страшным и неудобным. Более того если там какой-нибудь bundle, то он может быть ещё и громадным. Чёрт ногу сломит. Жить можно, но довольно грустно. - помещаем содержимое проблемной части кода в
setTimeoutи ошибка падает в консоль уже на следующем тике работы js-движка, без задействованияSystem.js - наблюдаем нормальный stack-trace.
для Angular2 альтернативы я пока не видел
angular-cli?
npm install -g angular-cli
ng new PROJECT_NAME
cd PROJECT_NAME
ng serve
del
Проблема в недообразованности.
Есть ЧТО мы хотим сделать и что МОЖНО сделать, а как это программируется (ЯваСкрипт это язык программирования) только КАЖЕТСЯ что ясно.
Вот приведу пример недообразованности:
JSON это что? это JavaScript object notation, то есть ЯЗЫК описания обьектов используя язык JavaScript
а в разговорах и везде используется как протокол передачи данных или как тип сервиса «передать джейсоном, вызвать джейсон»
и дело не в том что людям лень говорить JSON over HTTP, а в том что проще о таких вещах НЕ ДУМАТЬ…
JS был и до того как на нем придумали делать фронтенд. Мне кажется HTMLщики просто чувствовали себя ущербно из-за того что они не могут сделать сайт «полностью» без бакендеров. Вот это и привело к тренду программирования на JS.
Kстати отдельная тема для разговора «есть во всех браузерах». Херушки нету.
Потому как все бразуеры имплементируют реализацию языка сами. Нет производителя JavaScripta, а есть браузеры поддерживающие запуск текста на JS так, как им кажется верным. При должном развитии языка мы придем к ситуации в которой придется писать скрипт браузер депендент (как это было и слегка ощущуется и сейчас).
Кстати себя я не считаю «шибко образованным» скорее наоборот.
Обсуждалось недавно. Тренд JS возник из-за увеличения скорости движка, появления движка V8 — он увеличил на порядок (в 10 раз) скорость выполнения JS, И вот тогда и понеслось. Ибо появился скоростной «мотор».
А скоростной мотор — это всегда фан! ;-)
HexNeo > Кстати себя я не считаю «шибко образованным» скорее наоборот.
Это проходит со временем. ;-)
del
Для более удобной манипуляции css классами используется пакет "classnames".
//import classnames from 'classnames';
//let oneClass = classnames('foo', 'bar'); //значение "foo bar"
let oneClass = ['foo', 'bar'].join(' '); //значение "foo bar"
let isActive = true;
//let anotherClass = classnames({
// 'foo': true,
// 'bar': false,
// 'active': isActive
//}) // значение "foo active"
let anotherClass = [ 'foo', isActive ? 'active' : '' ].join(' ') // значение "foo active"
Свой проект можете писать на чем вам удобнее.
На работе ипользуем frontend — синтаксис CoffeeScript в Google closure и React, backend Java, db PL/SQL, еще 2 месяца назад иногда пользовался jQuery а так в основном PHP, и проблем нет, фирма платит за обучение…
Ну, не всем же платят за программирование, например на PL/1.
Поэтому народ и хочет писать на современных то языка и по современному. Тем более тренд есть к этому. А где тренд там и спрос на вакансии.
Имхо, конечно, имхо.
JavaScript 2016, а можно попроще?