Если у тебя в руках молоток, то всё вокруг кажется гвоздями

А так и должно быть, иначе vdom быстрый не имеет смысла, если в одних ситуациях реакт вызовет кучу холостых проверок, а вью или ещё кто - только нужные

Если у тебя в руках молоток, то всё вокруг кажется гвоздями

Норм ник

Спасибо ?

Если у тебя в руках молоток, то всё вокруг кажется гвоздями

это к чему вообще сказано?

К тому что у тебя всё будет обсервером

Кратко твой ник говорит о моей реакции когда я слышу "джей ЭС"

то есть походу react-final-form - это такой же mobx, но только ограниченный формами

react-final-form - это тот же redux-form только вместо глобального хранилища используется стейт в компоненте form

react-final-form - это тот же redux-form только вместо глобального хранилища используется стейт в компоненте form

ну вот сообщение выше опровергает это

react-final-form - это тот же redux-form только вместо глобального хранилища используется стейт в компоненте form

Нет

то есть походу react-final-form - это такой же mobx, но только ограниченный формами

Приктически

К тому что у тебя всё будет обсервером

И чем это плохо?

Там внутренний обсервер

И автор final form красвчик

Но это же ппц что такое надо изобретать

И чем это плохо?

Просто странно выглядит

Вот взять formik - просто отличное апи, и ничего над стейтом реакта не изобретено

Но блин обречено лагать с большими формами

Потому что цепочка ререндеров

Но это же ппц что такое надо изобретать

это надо изобретать, потому что как бы нам всем не хотелось, но virtual dom не работает мгновенно

это надо изобретать, потому что как бы нам всем не хотелось, но virtual dom не работает мгновенно

Так он вхолостую отрабатывает

Просто странно выглядит

Это всё субъективно. Правда у mobx есть и объективные недостатки.

Я не понимаю почему вы говорите о observable в контексте final-form, там стейт > reducer > diff > ререндер компонента, чем это отличается от redux?

Это всё субъективно. Правда у mobx есть и объективные недостатки.

Здравствуйте, у вас будет минутка поговорить об обсерваблах и пророке нашем мобиксе

кто-нибудь знает, что за шрифт в редакторе?

Я не понимаю почему вы говорите о observable в контексте final-form, там стейт > reducer > diff > ререндер компонента, чем это отличается от redux?

Об обсерваблах только один говорит

Там создаётся стейт, и форма и поля подписываются на изменения

А rff уже стейт меняет по нотификациям

кто-нибудь знает, что за шрифт в редакторе?

Operator mono чекни

подскажите пожалуйста в чем может быть проблема? отваливаются виджеты вк и ютуба, после смены и возврата на предыдущий роут (mainpage => other page => back to mainpage). ошибка в консоли: Blocked a frame with origin “https://www.youtube.com” from accessing a cross-origin frame. вк вообще молчит. юзаем react-router5 виджеты встроены так: два скрипта от вк и гугл апи в index.html. дивы, куда скрипты подставляют фреймы, рендерятся в отдельно в боди. предполагаю, что проблема в том, что домен на http, это так? Тогда непонятно, почему на первую загрузку все ок. спасибо )

Я не понимаю почему вы говорите о observable в контексте final-form, там стейт > reducer > diff > ререндер компонента, чем это отличается от redux?

Тем что можно управлять

Какие поля слушать а какие нет

Очень крутая штука

это надо изобретать, потому что как бы нам всем не хотелось, но virtual dom не работает мгновенно

реакт просто использует не самую эффективную технику virtual dom. Есть более эффективные техники шаблонизации. Например реакт генерирует объекты описывающие вертску только для того чтобы сравнить с предыдущей структурой в памяти и применить изменения, когда можно например применять изменения на лету не генерируя объекты и не нагружать сборщик мусора. Кому интересно посмотрите на https://github.com/google/incremental-dom

И через форм спай забирать что нужно

Не вызывая ререндера

реакт просто использует не самую эффективную технику virtual dom. Есть более эффективные техники шаблонизации. Например реакт генерирует объекты описывающие вертску только для того чтобы сравнить с предыдущей структурой в памяти и применить изменения, когда можно например применять изменения на лету не генерируя объекты и не нагружать сборщик мусора. Кому интересно посмотрите на https://github.com/google/incremental-dom

Как ты будешь генерировать на лету например объекты для сравнения с сервер сайда

Говоря о более оптимальных вариантах все почему-то забывают уточнить сколько кейсов охватывает их решение и сколько реакт

Который задумывается даже о пользователях scalajs

Nuff said

ну по хорошему иметь выбор для конкретного проекта

те юзать один стек с вариативным дом-ом

И проектировать все заранее, и писать без багов

1) Так на watterfall и делают

вот только для заказчиков это не эффективно

Еее кровавый энтерпрайз

да я сам по агилу работаю)

Это на самом деле ни для кого не эффективно

ну до появления интернетиков ваттерфолл был топом, ибо там рынок по другому работал

конкуренция не такой была

Как ты будешь генерировать на лету например объекты для сравнения с сервер сайда

Можешь раскрыть мысль? Под сравнением на лету подразумевается что jsx, например return <div class="some"> {AppState.title} <div>text</div> </div>будет компилироваться не объекты, которые надо создавать а потом сборщик мусора будет их чистить return { tag: 'div', attr: {class: 'some'} children: [ AppState.title, { tag: 'div', children: 'text' } ] }а в вызов функции o('div'), a('class', 'some') t(AppState.title), o('div'), t('text'), c() c()где функция o(tagName) переместит указатель на следующий элемент в структуре виртуального дома в памяти и сравнит его с тегом в аргументах, дальше функция a() будет сравнивать по очереди переданный аттрибут с текущим аттрибутом текущего элемента в памяти и применять изменения. Дальше если встретится с() то указатель на текущий элемент виртуального дума переместится на следующий элемент в списке на уровне выше. В общем будет точно такое же сравнение виртуального дума но на лету, без генерации объектов

Можешь раскрыть мысль? Под сравнением на лету подразумевается что jsx, например return <div class="some"> {AppState.title} <div>text</div> </div>будет компилироваться не объекты, которые надо создавать а потом сборщик мусора будет их чистить return { tag: 'div', attr: {class: 'some'} children: [ AppState.title, { tag: 'div', children: 'text' } ] }а в вызов функции o('div'), a('class', 'some') t(AppState.title), o('div'), t('text'), c() c()где функция o(tagName) переместит указатель на следующий элемент в структуре виртуального дома в памяти и сравнит его с тегом в аргументах, дальше функция a() будет сравнивать по очереди переданный аттрибут с текущим аттрибутом текущего элемента в памяти и применять изменения. Дальше если встретится с() то указатель на текущий элемент виртуального дума переместится на следующий элемент в списке на уровне выше. В общем будет точно такое же сравнение виртуального дума но на лету, без генерации объектов

идея интерсная кстати

реально можно уменьшить нагрузку на GC

Можешь раскрыть мысль? Под сравнением на лету подразумевается что jsx, например return <div class="some"> {AppState.title} <div>text</div> </div>будет компилироваться не объекты, которые надо создавать а потом сборщик мусора будет их чистить return { tag: 'div', attr: {class: 'some'} children: [ AppState.title, { tag: 'div', children: 'text' } ] }а в вызов функции o('div'), a('class', 'some') t(AppState.title), o('div'), t('text'), c() c()где функция o(tagName) переместит указатель на следующий элемент в структуре виртуального дома в памяти и сравнит его с тегом в аргументах, дальше функция a() будет сравнивать по очереди переданный аттрибут с текущим аттрибутом текущего элемента в памяти и применять изменения. Дальше если встретится с() то указатель на текущий элемент виртуального дума переместится на следующий элемент в списке на уровне выше. В общем будет точно такое же сравнение виртуального дума но на лету, без генерации объектов

Кого? Виртуального дума?

Дум 2

Дум 2

Дум 2.0

Все качаю вады для дума, хватит на сегодня реакта

такой вопрос, есть элемент div с лежащими внутри input type=radio, h5 и img, div сам по себе кликабелен и имеет свой data-attribute, само-собой когда кликаю на div dataset мне приходит но когда я кликаю на текст который лежит внутри div dataset теряееться, модно ли как-то сднлать что-бы div все перекрывал сверху

заменить div на label и твой клик на label будет передавать checked на radio, соответственно onChange можно повесить на него

ERROR: S client not available

такой вопрос, есть элемент div с лежащими внутри input type=radio, h5 и img, div сам по себе кликабелен и имеет свой data-attribute, само-собой когда кликаю на div dataset мне приходит но когда я кликаю на текст который лежит внутри div dataset теряееться, модно ли как-то сднлать что-бы div все перекрывал сверху

Pointer-events: none

@itsjohncena спасибо

никогда не видел подобного решения

потому что это костыль

но раз тебе подошёл — ради бога

ну как еще, баблингом баловаться, всем дочерним дата атрибуты ставаить, z-index который не помог

?

йо

а есть канал react native?

в инфе канала ссылка

webpack: кто знает плагин для маштабирования картинок?

webpack: кто знает плагин для маштабирования картинок?

@webpack_ru

Спасибо

Народ, не подскажите есть ли css фреймворки для реакта с встроенными в компоненты styled components? Все что пока встречал требует отдельного линка на сразу весь css файл, а это по-моему не очень рационально, учитывая декларативный подход реакта.

Или может есть причина по которой так не делают, буду рад услышать мнения

rebass

Это то что нужно, но сами компоненты там мягко говоря не очень

Как sc заюзать на проекте отдельный верстальщик и уже почти вся верстка есть ?

Как sc заюзать на проекте отдельный верстальщик и уже почти вся верстка есть ?

Переписывать или смириться

Переписывать или смириться

Было б время, переписал бы, а то у меня от класснеймс кровь из глаз

Как sc заюзать на проекте отдельный верстальщик и уже почти вся верстка есть ?

а что, одно другое отменяет? разбить на компоненты и обосновать необходимость переписывания.

а что, одно другое отменяет? разбить на компоненты и обосновать необходимость переписывания.

Там вся верстка через тоггл классов сделана

И искать все эти состояния в css мне лень

Там вся верстка через тоггл классов сделана

через что?

Там вся верстка через тоггл классов сделана

Перепиши на css modules, здоровее будешь

Перепиши на css modules, здоровее будешь

ну или вот да, это быстрее будет

И искать все эти состояния в css мне лень

хороший верстальщик так-то доку должен написать, если речь о чём-то сложнее двух экранов

Перепиши на css modules, здоровее будешь

Кстати вариант

Но там ещё и б*м ?