а здесь нет случайно практикующих gopherjs с reactjs?

а здесь нет случайно практикующих gopherjs с reactjs?

Зачем такой изврат?)

)))

народ, а как вы модалки организуете в приложении? react + redux?

react-portal?

надо уточнить, наверное. У меня в приложении около 15 модалок. 15 порталов рендрить?

ребят может кто подсказать в чем проблема при реакт роутинге выпадает twitter widgets ?

http://stackoverflow.com/questions/28525189/twitter-widget-only-working-in-the-first-loading-then-fails

народ, а как вы модалки организуете в приложении? react + redux?

вручную, с помощью react-onclickout

Народ, я тут вдруг осознал что jsx и виртуальный дум в том виде в котором они сейчас существуют это порочная идея и по производительности всегда будет проигрывать решениям где используется компилирование шаблонов (Angular, Ember). Смотрите - компилятор jsx принимает на вход разметку разбавленными js-выражениями и превращает все это во вложенный вызов функций React.createElement. В результате получается что эта функция никак не может знать где у нас статические данные а где данные которые являются результатом выполнения выражения и как результат мы приходим к тому что нам нужно проверять каждый элемент и атрибуты на изменения что и делает виртуальный дум реакта. А теперь сравним это с вариантом компилирования шаблонов - независимо от того как много у нас может быть разметки, точек, где происходит привязка данных, намного меньше - в итоге за счет метаинформации о том где в шаблоне находятся выражения а где обычная статическая разметка, при изменении данных достаточно пройтись всего лишь по небольшому количеству точек где присходит интерпретация и произвести сравнения в то время как реакту прийдется сравнивать всю структуру div-ов и атрибутов. Кто что думает по этому поводу?

https://habrahabr.ru/company/oleg-bunin/blog/310868/

https://habrahabr.ru/company/oleg-bunin/blog/310868/

2k LOC и 700 байт в гзипе – интересно

https://medium.com/@mweststrate/how-to-safely-use-react-context-b7e343eff076#.ot0lmal4z

https://medium.com/@kitze/configure-create-react-app-without-ejecting-d8450e96196a#.ybxz97tzb

Народ, я тут вдруг осознал что jsx и виртуальный дум в том виде в котором они сейчас существуют это порочная идея и по производительности всегда будет проигрывать решениям где используется компилирование шаблонов (Angular, Ember). Смотрите - компилятор jsx принимает на вход разметку разбавленными js-выражениями и превращает все это во вложенный вызов функций React.createElement. В результате получается что эта функция никак не может знать где у нас статические данные а где данные которые являются результатом выполнения выражения и как результат мы приходим к тому что нам нужно проверять каждый элемент и атрибуты на изменения что и делает виртуальный дум реакта. А теперь сравним это с вариантом компилирования шаблонов - независимо от того как много у нас может быть разметки, точек, где происходит привязка данных, намного меньше - в итоге за счет метаинформации о том где в шаблоне находятся выражения а где обычная статическая разметка, при изменении данных достаточно пройтись всего лишь по небольшому количеству точек где присходит интерпретация и произвести сравнения в то время как реакту прийдется сравнивать всю структуру div-ов и атрибутов. Кто что думает по этому поводу?

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

если кто пропустил, то вот крутое видео по react events https://www.youtube.com/watch?v=dRo_egw7tBc

Народ, я тут вдруг осознал что jsx и виртуальный дум в том виде в котором они сейчас существуют это порочная идея и по производительности всегда будет проигрывать решениям где используется компилирование шаблонов (Angular, Ember). Смотрите - компилятор jsx принимает на вход разметку разбавленными js-выражениями и превращает все это во вложенный вызов функций React.createElement. В результате получается что эта функция никак не может знать где у нас статические данные а где данные которые являются результатом выполнения выражения и как результат мы приходим к тому что нам нужно проверять каждый элемент и атрибуты на изменения что и делает виртуальный дум реакта. А теперь сравним это с вариантом компилирования шаблонов - независимо от того как много у нас может быть разметки, точек, где происходит привязка данных, намного меньше - в итоге за счет метаинформации о том где в шаблоне находятся выражения а где обычная статическая разметка, при изменении данных достаточно пройтись всего лишь по небольшому количеству точек где присходит интерпретация и произвести сравнения в то время как реакту прийдется сравнивать всю структуру div-ов и атрибутов. Кто что думает по этому поводу?

А кто-то создал такой шаблонизатор? Ну чтоб он кроме таких чудесных оптимизаций ещё и работал быстро, ато glimmer2 и ng2 не демонстрируют впечатляющих результатов.

хз что даже думать по этому поводу

но реактовский pushing web forward немного начинает бесить

надо уточнить, наверное. У меня в приложении около 15 модалок. 15 порталов рендрить?

так у тебя не сразу же все 15 окон открыты, поэтому да, 15 реакт порталов вполне заходит

А кто-то создал такой шаблонизатор? Ну чтоб он кроме таких чудесных оптимизаций ещё и работал быстро, ато glimmer2 и ng2 не демонстрируют впечатляющих результатов.

vue

vue

если там всё так замечательно, то почему во второй версии будет использоваться виртуальный дом вместо "мета-информации" ? и почему вторая версия вдруг стала значительно быстрее работать? :)

если там всё так замечательно, то почему во второй версии будет использоваться виртуальный дом вместо "мета-информации" ? и почему вторая версия вдруг стала значительно быстрее работать? :)

Я ж не говорю про то, что виртуал дом такой плохой) Ты спросил, сделал ли кто-нить быстрый шаблонизатор, я ответил.

Я ж не говорю про то, что виртуал дом такой плохой) Ты спросил, сделал ли кто-нить быстрый шаблонизатор, я ответил.

Ну имелось в виду сделал ли кто-нибудь такой быстрый шаблонизатор, который будет хотябы на том же уровне как и виртуал дом реализации :)

Ну имелось в виду сделал ли кто-нибудь такой быстрый шаблонизатор, который будет хотябы на том же уровне как и виртуал дом реализации :)

Написал поэму, потом понял, что дико ошибся в самом начале, стер. Наверное, нет.

Всем привет. Два вопроса делаю binding, подключил reaact-addons-linked-state-mixins. Но ругается на linkState

и второй вопрос, линтер ругается на св-ва actions, history и т.д. правильно их объявляю в интерфейсе, или это делается по другому?

Чувак, выброси миксины и подключи es6

не совсем понял, отказаться от typeScript и перейти на es6?

Как я помню миксины деприкейтед в последних версиях реакта

Ты какую версию используешь?

13?

И зачем тянуть тайпскрипт в проект?

миксины не депрекейтед, но работают они только с React.createClass, а не с es6 классами

И заюзай react bootstrap, если у тебя вся разметка на нем, намного чище jsx будет

Ты какую версию используешь?

15

И зачем тянуть тайпскрипт в проект?

Решили попробовать typeScript, почему нет)

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

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

а что делать с inkState, почему он не подключился?

https://facebook.github.io/react/docs/two-way-binding-helpers.html

по этому примеру и делал

я к тому, что его в 15 уже задепрекейтили и не надо на него код завязывать

Понял. Т.е лучше получать св-ва через refs?

ну просто держи в стейте значения инпутов и на onChange меняй их

или посмотри redux form

ок спасибо

это сделано так понимаю из-за производительности?

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

Делать к конструкторе .bind?

Выглядит убого, но да

или в классе писать метод?

https://daveceddia.com/avoid-bind-when-passing-props/

вот статейка на тему

там много способов

можно сказать целых три

method = () => {}

если stage 0 используется, то лучше метод класса через () =>

Как меьод класса

эм, а как их метода класса получить доступ к конкретному инстансу?

оговорка. Метод инстанса будет

ну формально это метод инстанса, конечно )

просто записан по-другому

это прям часть спеки или сайд-эффект от бабеля?

это https://github.com/tc39/proposal-class-public-fields

даже stage 2 уже

это прям часть спеки или сайд-эффект от бабеля?

Часть предложенной спеки с которой есть проблемы и возможно будут переделывать

чето я с утра туплю жестко

это получается мы кладем в свойство класс стрелочную функцию, у которой лексический контекст?

просиходит примерно тоже самое, как будто в конструкторе добавили)

Кто нибудь работает на больших проектах, где вебпак показывает больше 3000-5000 модулей, у вас сколько время сборки и пересборки при изменении файла?

2к модулей, 1.5 секунды где-то

время сборки ~40-45

Народ, я тут вдруг осознал что jsx и виртуальный дум в том виде в котором они сейчас существуют это порочная идея и по производительности всегда будет проигрывать решениям где используется компилирование шаблонов (Angular, Ember). Смотрите - компилятор jsx принимает на вход разметку разбавленными js-выражениями и превращает все это во вложенный вызов функций React.createElement. В результате получается что эта функция никак не может знать где у нас статические данные а где данные которые являются результатом выполнения выражения и как результат мы приходим к тому что нам нужно проверять каждый элемент и атрибуты на изменения что и делает виртуальный дум реакта. А теперь сравним это с вариантом компилирования шаблонов - независимо от того как много у нас может быть разметки, точек, где происходит привязка данных, намного меньше - в итоге за счет метаинформации о том где в шаблоне находятся выражения а где обычная статическая разметка, при изменении данных достаточно пройтись всего лишь по небольшому количеству точек где присходит интерпретация и произвести сравнения в то время как реакту прийдется сравнивать всю структуру div-ов и атрибутов. Кто что думает по этому поводу?

Приветствую! В этой статье обсуждают порочность идеи https://habrahabr.ru/post/311226/