должно с ним работать

Гуд, Property Lookup - то что надо

Спасибо, Борис что разъяснил)

Реакт до сих пор крут, или уже надо новый фреймворк учить?

пора начинать новый учить

Какой?

пока непонятно

то есть реакт уже попахивает?

во фронтенде все что старше двух недель уже попахивает

как же непонятно, cycle или Elm lang. :3

ммаксимум хипстота

purescript?

fable https://fsprojects.github.io/Fable/samples/virtualdom/index.html

кложа более хипстотная чем пурескрипт

jQuery

Ну вообще если не шутить про актуальность чего-либо в фронтенде, кто считает в каком направлении всё движется? На мой взгляд реакт сейчас более чем актуален и долго таким останется просто потому что это грамотная парадигма. Потенциально флаксовые-редаксовые концепты-бойлерплейты утрясутся и превратятся во что-то более устойчивое, но допускаю, что и нет ) Как я понимаю перспективное направление это вещи типа morphdom, потому как они позволяют не зависеть от от virtual dom tree и соответственно будущие фреймворки не должны будут привязываться к тому, чтобы работать с виртуальным деревом, а тупо могут обновлять ДОМ так, как им хочется. То есть имеем на одну абстракцию меньше при грубо говоря том же функционале, а это мега ценно. Вдогонку вчера в chrome 53 beta приземлился shadow dom v1 (http://blog.chromium.org/2016/08/chrome-53-beta-shadow-dom.html), так что вся история в веб компонентами будто не затихает ) Кто-то поправит что-нибудь? Что-то не так вижу?

все так

еще ангуляр соснет

еще ангуляр соснет

говорят, на замену ему придет aurelia

говорят, на замену ему придет aurelia

слишком маленькое комьюнити, тоже соснет

говорят, на замену ему придет aurelia

посоны, какая аурелия

захлонет как и взлетело

тот же метеор ток на новом стеке

тот же метеор ток на новом стеке

вроде аврелия это более адекватный ангуляр v1.x

А что еще можно ожидать от людей в сообществе посвящённом react.js :) Вот мне интересно, кто пользовался и кто что думает на тему relay?

слишком маленькое комьюнити, тоже соснет

не сказал бы, они довольно неплоо раскрутились еще на стадии беты

куда они там раскрутились на стадии беты? http://www.npmtrends.com/react-vs-angular-vs-jquery-vs-webcomponents.js-vs-aurelia-framework

угар

у аурелии там локально скачивается вроде как

Ввёл в поиске посомтреть что за aurelia, попал на хабр страницу где ни строчки примера кода, но прикреплён видос ?

А под ним осталось написать "aurelia удобнее чем javascript"

Если у нас есть SPA с серверным рендерингом, в котором общая шапка и боковая панель и куча разнородных страниц, и нам надо грузить сначала только компоненты, нужные той странице, которую мы показываем, а при переключении страницы на клиенте, если для новой страницы каких-то компонентов не хватает, показать плашку "загрузка", догрузить необходимые компоненты и после этого переклчить страницу. Реализовывал ли кто-нибудь подобное?

куда они там раскрутились на стадии беты? http://www.npmtrends.com/react-vs-angular-vs-jquery-vs-webcomponents.js-vs-aurelia-framework

jQuery – сила React – могила

Если у нас есть SPA с серверным рендерингом, в котором общая шапка и боковая панель и куча разнородных страниц, и нам надо грузить сначала только компоненты, нужные той странице, которую мы показываем, а при переключении страницы на клиенте, если для новой страницы каких-то компонентов не хватает, показать плашку "загрузка", догрузить необходимые компоненты и после этого переклчить страницу. Реализовывал ли кто-нибудь подобное?

Так в чём сложность?

Если у нас есть SPA с серверным рендерингом, в котором общая шапка и боковая панель и куча разнородных страниц, и нам надо грузить сначала только компоненты, нужные той странице, которую мы показываем, а при переключении страницы на клиенте, если для новой страницы каких-то компонентов не хватает, показать плашку "загрузка", догрузить необходимые компоненты и после этого переклчить страницу. Реализовывал ли кто-нибудь подобное?

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

вопрос про code splitting, а не про ssr в целом )

У тебя же при роуте на клиетн будет меняться только один компонент, на onter повесишь лоадер

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

Важно, чтобы при загрузке страницы не грузить на клиент компоненты, которые для текущей страницы и для общей части не нужны

Важно, чтобы при загрузке страницы не грузить на клиент компоненты, которые для текущей страницы и для общей части не нужны

в смысле лол

сервер рендеринг это просто рендеринг

как твое клиенсткое приложение работает, так оно и должно работать при сервер рендеринге

в общем, предположим, что сервер рендеринга нет и он не нужен, это в данном случае не принципиально

https://webpack.github.io/docs/code-splitting.html

у аурелии там локально скачивается вроде как

ставится через jspm, а в jspm регистре прибит линк на установку из npm

как добавить стиль к рут элементу реакта?

то бишь тот, что с data-reactroot

как добавить стиль к рут элементу реакта?

как и к любому другому?...)

про require.ensure, допустим, я делаю так require.ensure('page2', ...), require.ensure('page3', ...), и если и на page2, и на page3 нужен компонент Input, то он у меня загрузится дважды при переключении последовательно на page2 и page3, а этого хотелось бы избежать, или я не прав?

А где вы собираетесь его хранить?

в каком из бандлов?

Важно, чтобы при загрузке страницы не грузить на клиент компоненты, которые для текущей страницы и для общей части не нужны

Бандлить аппу, на сервере будет общий код всего приложения

он у вас либо один раз но всегда будет грузиться (вынести в вендоры), либо дублироваться каждый раз

Хотя при сервер рендеринге это не критично, да.

про require.ensure, допустим, я делаю так require.ensure('page2', ...), require.ensure('page3', ...), и если и на page2, и на page3 нужен компонент Input, то он у меня загрузится дважды при переключении последовательно на page2 и page3, а этого хотелось бы избежать, или я не прав?

ну на то и вебпак, чтоб не дважды название ensure как бы намекает

Ну вообще если не шутить про актуальность чего-либо в фронтенде, кто считает в каком направлении всё движется? На мой взгляд реакт сейчас более чем актуален и долго таким останется просто потому что это грамотная парадигма. Потенциально флаксовые-редаксовые концепты-бойлерплейты утрясутся и превратятся во что-то более устойчивое, но допускаю, что и нет ) Как я понимаю перспективное направление это вещи типа morphdom, потому как они позволяют не зависеть от от virtual dom tree и соответственно будущие фреймворки не должны будут привязываться к тому, чтобы работать с виртуальным деревом, а тупо могут обновлять ДОМ так, как им хочется. То есть имеем на одну абстракцию меньше при грубо говоря том же функционале, а это мега ценно. Вдогонку вчера в chrome 53 beta приземлился shadow dom v1 (http://blog.chromium.org/2016/08/chrome-53-beta-shadow-dom.html), так что вся история в веб компонентами будто не затихает ) Кто-то поправит что-нибудь? Что-то не так вижу?

Реакт хорош но почему-то до сих пор нет ни одного действительно большого и сложного опенсорс проекта. По этому пункту пока лидирует первый ангуляр на котором написан наш телеграмовский чат (чего только стоит один файл с директивами https://github.com/zhukov/webogram/blob/master/app/js/directives.js, интересно сколько бы компонент получилось бы на реакте?)

Реакт хорош но почему-то до сих пор нет ни одного действительно большого и сложного опенсорс проекта. По этому пункту пока лидирует первый ангуляр на котором написан наш телеграмовский чат (чего только стоит один файл с директивами https://github.com/zhukov/webogram/blob/master/app/js/directives.js, интересно сколько бы компонент получилось бы на реакте?)

> чего только стоит один файл с директивами вот именно ))

Реакт хорош но почему-то до сих пор нет ни одного действительно большого и сложного опенсорс проекта. По этому пункту пока лидирует первый ангуляр на котором написан наш телеграмовский чат (чего только стоит один файл с директивами https://github.com/zhukov/webogram/blob/master/app/js/directives.js, интересно сколько бы компонент получилось бы на реакте?)

главное что лидирует по сложным коммерчески успешным проектам, а не по каким-то опенсорс проектам

ну да, спорный показатель. Как раз про ангуляр все кричали, что серьёзных проектов на нём мало делают, а на реакт перескачили сразу много громких имён

он у вас либо один раз но всегда будет грузиться (вынести в вендоры), либо дублироваться каждый раз

Это я как раз понимаю, я хотел узнать, есть ли способ грузить не сразу, но и не дублировать

грузить не сразу? откуда?

ERROR: S client not available

из первого бандла? из второго? из вендоров?

я не знаю, для этого и спрашиваю

Друзья, собрали Open Source примеры, библиотеки и Starter Kits для создания Telegram-ботов на любом языке программирования. Отправляйте Pull Requests (или просто создайте Issue и я сам добавлю вашу ссылку) и подписывайтесь на обновления в GitHub: + https://github.com/DenisIzmaylov/awesome-telegram-bots

компонент должен грузиться внутри какого то бандла, он либо будет отдельный для каждого бандла, либо на каждой странице будет грузиться какой то "общий" бандл который содержит все необходимое.

обычно дублирующиеся части выносят в vendors/чтотоеще

и они грузятся на каждой странице.

Причем дубликаты определяются автоматически плагином вебпака (забыл название)

CommonsChunkPlugin

Всем привет. Александр Бурцев PM в МФТИ ЦИОТ, образовательные платформы. CEO BramaBrama.com разработка web сервисов на Python/Django. Есть задачи в области mobile dev. Узнал о группе через канал devconf, где делал доклад по конвейерной разработки сложных web-проектов.

Есть причины, почему не следует использовать react-router?

Есть причины, почему не следует использовать react-router?

нет

Мне бы поудобнее организовать nested routing.

Я просто не особо имею с ним опыта, допустим и интересуюсь. Чтобы я мог взять лучше.

ну на то и вебпак, чтоб не дважды название ensure как бы намекает

Если у меня есть require.ensure('page2, ...) и require.ensure('page3', ...), и в обоих page2 и page3 есть require('someComponent'), то someComponent дублируется в обоих бандлах (page2 и page3). При этом на page1 этого someComponent нет и если пользователь изначально заходит на page1, то someComponent на клиент приезжать не должен (так что CommonsChunkPlugin не вариант), при переключении на page2 и page3 (без перезагрузки страницы) someComponent приедет на клиент дважды. Чтобы избежать этого дублирования, можно в page2 и page3 рекваерить someComponent тоже через ensure, догда он уйдет в отдельный бандл, но при переключении с page1 на page2 загрузится последовательно после загрузки page2, а хочется, чтобы параллельно. Можно, конечно, настолько не упарываться, вряд ли на этом можно много выиграть, но чисто из спортивного интереса

всё так, только насчёт того, что "последовательно" загрузится не уверен

всё так, только насчёт того, что "последовательно" загрузится не уверен

Посмотрел сборку webpack'а, someComponent начнет загружаться только тогда, когда в page2 или page3 дойдет до того места, где мы делаем require.ensure('someComponent', ...), так что последовательно

https://twitter.com/jckarter/status/762683017466744832

https://twitter.com/jckarter/status/762683017466744832

https://twitter.com/liabru/status/763005844124557312

Там человек пишет на джсе настоящие демо в нормальных компо для нормальных демопати, а не в инвалидных категориях.

https://twitter.com/liabru/status/763005844124557312

пишет, что видео не может быть воспроизведено в моем браузере( Последний хром...

Ребята подскажите плиз какую проблему решает redux-saga?

Там же в ридми написано Работа с сайд эффектами

Асинхронными экшнами

То есть альтернатива redux-thunk?

По сути

Я не понимаю в чем профит

пишет, что видео не может быть воспроизведено в моем браузере( Последний хром...

Там демо в килобайт есть кода есть

Я не понимаю в чем профит

По началу сложновато понять, для этого надо прочитать почти всю доку, последовательно. Благо она хорошо написана.

вкратце это middleware для workflow management, то есть с ней можно описывать целые долгоживущие процессы в приложении. А благодаря генераторам легко тестировать без моков

вкратце это middleware для workflow management, то есть с ней можно описывать целые долгоживущие процессы в приложении. А благодаря генераторам легко тестировать без моков

а ещё там говорится, что легко разруливать рейсы шмейсы и прочее.