Реально. Только имеет смысл в этот метод название переменной передавать строкой и смотреть на window[var], а то примитив просто скопируется по значению и никаких ссылок

const waitFor = (flagName) => { new Promise(resolve => { const interval = setInterval(() => { if (window[flagName] === true) { resolve(); clearInterval(interval); } }, 200); }); } что-то такое и await waitFor("var") ?

const waitFor = (flagName) => { new Promise(resolve => { const interval = setInterval(() => { if (window[flagName] === true) { resolve(); clearInterval(interval); } }, 200); }); } что-то такое и await waitFor("var") ?

ага, только return new Promise...

И есть ли гарантия что если я его заимпортирую в двух местах это будет не два экземпляра синглтона ?

много способо сделать сингтон на самом деле

https://medium.com/@dmnsgn/singleton-pattern-in-es6-d2d021d150ae

Я вот эту штуку нашел может попробую https://github.com/Caesor/react-singleton

бля

ты реакт класс хочешь сделать синглтоном ?

да думаю обычный класс можно запилить

ага, только return new Promise...

работает, ееее

https://github.com/styled-components/styled-components/issues/2146

Это больше выглядит как баг .memo....

Ага

если с recompose/pure работает нормально, то это будет и правда memo

у меня в новом проекте все неймед экспортс

https://codesandbox.io/s/64184y9qk

Ну и костыли...

Чет реакт все меньше радует последнее время

а вроде писали, что будет проверка, чтобы был именно модуль, а не объект с ключом default просто используйте export default :)

Вот почему нельзя было сделать suspense( <div>Loading...</div>, <Component /> )

react/memo.js at master · facebook/react · GitHub https://github.com/facebook/react/blob/master/packages/react/src/memo.js

а вроде писали, что будет проверка, чтобы был именно модуль, а не объект с ключом default просто используйте export default :)

export default Очень нет

Вот почему нельзя было сделать suspense( <div>Loading...</div>, <Component /> )

Ты можешь написать хелпер и сделать как тебе удобно, держу в курсе

Мемо - это не декоратор.

Это отдельный тип компонента.

Ты можешь написать хелпер и сделать как тебе удобно, держу в курсе

"классика" реакта, зачем делать нормально, если можно написать хелпер. Нуу, только с react-dom чет не прокатит

Мемо - это не декоратор.

УДОБНО

Тут у меня сразу вопрос насчет работы мемоизации в компонентах В класс-компонентах коллбеки можно положить в метод, чтобы они не пересоздавались в рендере. Что делать с SFC, в котором коллбеки никуда не положить? У меня есть редактор из X айтемов, и при редактировании одного айтема происходит ререндер всех айтемов тупо из-за того, что коллбеки заново создаются и это типа другой проп.

"классика" реакта, зачем делать нормально, если можно написать хелпер. Нуу, только с react-dom чет не прокатит

Бля, ну а кто-то подумает "че за говеная функция, лучше бы компонентом сделали". Это субъектив пошел

Тут у меня сразу вопрос насчет работы мемоизации в компонентах В класс-компонентах коллбеки можно положить в метод, чтобы они не пересоздавались в рендере. Что делать с SFC, в котором коллбеки никуда не положить? У меня есть редактор из X айтемов, и при редактировании одного айтема происходит ререндер всех айтемов тупо из-за того, что коллбеки заново создаются и это типа другой проп.

Делай pureComponent

Я же показывал не раз как корректно делать колбеки.

Бля, ну а кто-то подумает "че за говеная функция, лучше бы компонентом сделали". Это субъектив пошел

ты уже чет на другой вопрос отвечаешь...

Делай pureComponent

Я уже так сделал. Но я не хочу переводить все компоненты в классы из-за этого Я бы вынес это в эффектор и был бы #антибугурт, но с несколькими инстансами работать нормального способа пока нет

УДОБНО

Да. Мемо отвечает спеке. Если ты опираешься не на спеку, а реализацию, то ты мудак.

ты уже чет на другой вопрос отвечаешь...

В смысле на другой. Я про саспенс отвечаю, не про мемо

Да. Мемо отвечает спеке. Если ты опираешься не на спеку, а реализацию, то ты мудак.

Какая спека?

Тут у меня сразу вопрос насчет работы мемоизации в компонентах В класс-компонентах коллбеки можно положить в метод, чтобы они не пересоздавались в рендере. Что делать с SFC, в котором коллбеки никуда не положить? У меня есть редактор из X айтемов, и при редактировании одного айтема происходит ререндер всех айтемов тупо из-за того, что коллбеки заново создаются и это типа другой проп.

recompose? Или не спасет?

Но насчет мемо, хочу внести 5 копеек и сказать, что если бы SFC изначально транспилился в какой-нибудь объект, добавить в него мемо было бы проще без плясок в заворачивание ?

Но тогда теряется смысл SFC, типа "это просто функция"

Какая спека?

Спека того что такое компонент и как он должен работать. Я хз как sc биндятся к компонентам. Если они считают, что компонентом не может быть объект, то это нарушение спеки.

Тебе нигде не сказано, что объект не может восприниматься как компонент.

@kelin2025

Ответственность JSX - отвечать за отображение DOM блоков. А не разруливать роутинг и мемоизацию - это же бред

Либо нам нужен еще один какой-то синтаксис \ теги или пометки для JSX для инкапсулирования логики, если хочется что-то описать декларативно

Но это не должен быть абсолютно тот же JSX !

Это же ясно как день. На Бали. В июле. ...

Почему нет <If>...<Else>...?? И т.п.? Потому что должна соблюдаться семантика - синтаксическая инкапсуляция абстракций

Ответственность JSX - отвечать за отображение DOM блоков. А не разруливать роутинг и мемоизацию - это же бред

С чего ты это взял?

Не вижу противоречий моего утверждения и твоего

Не вижу противоречий моего утверждения и твоего

Я к тому что это не вкусовщина. Жир крнкпеиный факт - логика в JSX - размазывание

С чего ты это взял?

с полочки

Сам придумал - сам обиделся.

+

Как с экспортами

Спека того что такое компонент и как он должен работать. Я хз как sc биндятся к компонентам. Если они считают, что компонентом не может быть объект, то это нарушение спеки.

Ткни где указано что компонент может быть объектом, первый раз слышу

Ткни где указано что компонент может быть объектом, первый раз слышу

А где сказано, что он не может им быть? По спеке вообще не сказано чем компонент не должен являться.

Я всего лишь предположил возможность легко добавлять фичи в компоненты. Использовать объект вместо функции. Не было бы никаких проблем - добавить проп memo и пускай реакт его чекает и думает, ререндерить ему или нет. Причем тут блять JSX, ему вообще в данном случае пофиг, что там за мемо

А что возвращал React.createClass?

А где сказано, что он не может им быть? По спеке вообще не сказано чем компонент не должен являться.

О какой спеке речь?

А что возвращал React.createClass?

ох если бы я юзал реакт до es6

О какой спеке речь?

В данном случае о документации реакта. В ней не сказано что такое компонент на низком уровне. Но почему то все подумали, что это только функции. Вот sc на это и напоролись. Здравствуйте.

Уверен что проблема решается тупо вырезанием варнинга в sc.

ERROR: S client not available

И что?

Сейчас это так. В следующей версии расширят определение.

Что сейчас и произошло, кстати.

Теперь у нас компонент - это объект особого вида.

См. Memo

Вот по-нормальному надо было его объектом сразу и сделать

А разве так изначально и не было?

Объектом особого вида и расширять при необходимости

Потому что мобх усаживает тебя на пенек с хуями под названием "магия" и обливает говном декораторов, со словами "теперь это твой дом, ублюдок"

Опять вброс про mobx) Извини но я не могу не ответить) Мне кажется заявлять что mobx такой плохой потому что в нем куча "магии" сродни тому как не зная что такое промисы и имея только знакомство с коллбеками заявлять что async/await является магией. В этой "магии" есть минус только в том что она немного повышает порог вхождения (как и async/await которые требуют знания промисов) но зато после того как разобрался с mobx все становится прозрачным и ничем не хуже редакса в плане предсказуемости 1) Mobx не заставляет "обливаться говном декораторов". Декоратор это просто синтаксический сахар который экономит две строчки кода. Хочешь не используй декораторы и вместо одной строчки class SomeStore { @observable user = ""; ... } пиши 3 строчки class SomeStore { _user = observable(""); get(){ return this._user.get() } set(val){ this._user.set(val) } ... } 2) А если уже геттеры и сеттеры жс каждутся магией то mobx не заставляет их использовать - это всего лишь синтаксический сахар обращения к полям, хочешь не используй но вместо простой записи <div> task's folder name: {this.props.task.project.folder.name} </div> придется на каждое обращение к полям добавлять .get() вызовы <div> task's folder name: {this.props.task.get().project.get().folder.get().name.get()} </div> 3) Если работа самого mobx кажется "магией" то на хабре есть несколько постов (https://habr.com/users/bgnx/posts) с подробным объяснением как он работает. А основной механизм работы mobx можно даже в объяснить в одном предложении: При оборачивании компонента observer-хокком mobx врапит рендер-функцию компонента и при вызове присваивает в глобальную переменную (а при выходе из функции возращает предыдуще значение) ссылку на инстанс этого компонента чтобы при обращении к observable-сторам (которые создаются через observable(val)) через .get()-вызов происходило добавление компонента из глобальной переменный в массив подписок этого observable-стора и потом при изменении значения стора через .set("") происходил вызов рендера всех компонентов из массива подписок Правда надо заметить что в mobx в массив подписок добавляется не сам компонент а объект реакции который уже будет вызывать сайд-эффект обновления компонента, а computed это некий подпид реакции который вместо сайд-эффекта перевычисляет функцию (добавляя таким образом мемоизацию) и решает глитчи (лишние вычисления). Но даже все это можно написать в 85 строчках кода (https://habr.com/post/349022)

Объектом особого вида и расширять при необходимости

Смысла нет особого. Но, кстати, ещё с 16.3 в реакте компонент - это и объект тоже.

react/isValidElementType.js at master · facebook/react · GitHub https://github.com/facebook/react/blob/master/packages/shared/isValidElementType.js

Sc с фораардрефом корректно работают?)

Опять вброс про mobx) Извини но я не могу не ответить) Мне кажется заявлять что mobx такой плохой потому что в нем куча "магии" сродни тому как не зная что такое промисы и имея только знакомство с коллбеками заявлять что async/await является магией. В этой "магии" есть минус только в том что она немного повышает порог вхождения (как и async/await которые требуют знания промисов) но зато после того как разобрался с mobx все становится прозрачным и ничем не хуже редакса в плане предсказуемости 1) Mobx не заставляет "обливаться говном декораторов". Декоратор это просто синтаксический сахар который экономит две строчки кода. Хочешь не используй декораторы и вместо одной строчки class SomeStore { @observable user = ""; ... } пиши 3 строчки class SomeStore { _user = observable(""); get(){ return this._user.get() } set(val){ this._user.set(val) } ... } 2) А если уже геттеры и сеттеры жс каждутся магией то mobx не заставляет их использовать - это всего лишь синтаксический сахар обращения к полям, хочешь не используй но вместо простой записи <div> task's folder name: {this.props.task.project.folder.name} </div> придется на каждое обращение к полям добавлять .get() вызовы <div> task's folder name: {this.props.task.get().project.get().folder.get().name.get()} </div> 3) Если работа самого mobx кажется "магией" то на хабре есть несколько постов (https://habr.com/users/bgnx/posts) с подробным объяснением как он работает. А основной механизм работы mobx можно даже в объяснить в одном предложении: При оборачивании компонента observer-хокком mobx врапит рендер-функцию компонента и при вызове присваивает в глобальную переменную (а при выходе из функции возращает предыдуще значение) ссылку на инстанс этого компонента чтобы при обращении к observable-сторам (которые создаются через observable(val)) через .get()-вызов происходило добавление компонента из глобальной переменный в массив подписок этого observable-стора и потом при изменении значения стора через .set("") происходил вызов рендера всех компонентов из массива подписок Правда надо заметить что в mobx в массив подписок добавляется не сам компонент а объект реакции который уже будет вызывать сайд-эффект обновления компонента, а computed это некий подпид реакции который вместо сайд-эффекта перевычисляет функцию (добавляя таким образом мемоизацию) и решает глитчи (лишние вычисления). Но даже все это можно написать в 85 строчках кода (https://habr.com/post/349022)

Опять утверждения, что магия это заебись. Даже влом что-либо отвечать, попиши на Vue тогда, если нравится

Sc с фораардрефом корректно работают?)

Да

Опять утверждения, что магия это заебись. Даже влом что-либо отвечать, попиши на Vue тогда, если нравится

Кстати, там и компоненты как объекты вроде :)

Опять утверждения, что магия это заебись. Даже влом что-либо отвечать, попиши на Vue тогда, если нравится

так в том то и дело что магии там нет

Да

Тогда проблемы у sc, а не реакта, так как memo сделан абсолютно так же как и forwardRef

Кстати, там и компоненты как объекты вроде :)

Само объявление компонента объектом - это хуево

Но то, что какой-нить React.memo возвращает объект - на кодовой базе проекта никак не сказывается, все подсказки и прочее работает заебись

Сделали бы тогда изначально React.sfc(() => ...)

Опять вброс про mobx) Извини но я не могу не ответить) Мне кажется заявлять что mobx такой плохой потому что в нем куча "магии" сродни тому как не зная что такое промисы и имея только знакомство с коллбеками заявлять что async/await является магией. В этой "магии" есть минус только в том что она немного повышает порог вхождения (как и async/await которые требуют знания промисов) но зато после того как разобрался с mobx все становится прозрачным и ничем не хуже редакса в плане предсказуемости 1) Mobx не заставляет "обливаться говном декораторов". Декоратор это просто синтаксический сахар который экономит две строчки кода. Хочешь не используй декораторы и вместо одной строчки class SomeStore { @observable user = ""; ... } пиши 3 строчки class SomeStore { _user = observable(""); get(){ return this._user.get() } set(val){ this._user.set(val) } ... } 2) А если уже геттеры и сеттеры жс каждутся магией то mobx не заставляет их использовать - это всего лишь синтаксический сахар обращения к полям, хочешь не используй но вместо простой записи <div> task's folder name: {this.props.task.project.folder.name} </div> придется на каждое обращение к полям добавлять .get() вызовы <div> task's folder name: {this.props.task.get().project.get().folder.get().name.get()} </div> 3) Если работа самого mobx кажется "магией" то на хабре есть несколько постов (https://habr.com/users/bgnx/posts) с подробным объяснением как он работает. А основной механизм работы mobx можно даже в объяснить в одном предложении: При оборачивании компонента observer-хокком mobx врапит рендер-функцию компонента и при вызове присваивает в глобальную переменную (а при выходе из функции возращает предыдуще значение) ссылку на инстанс этого компонента чтобы при обращении к observable-сторам (которые создаются через observable(val)) через .get()-вызов происходило добавление компонента из глобальной переменный в массив подписок этого observable-стора и потом при изменении значения стора через .set("") происходил вызов рендера всех компонентов из массива подписок Правда надо заметить что в mobx в массив подписок добавляется не сам компонент а объект реакции который уже будет вызывать сайд-эффект обновления компонента, а computed это некий подпид реакции который вместо сайд-эффекта перевычисляет функцию (добавляя таким образом мемоизацию) и решает глитчи (лишние вычисления). Но даже все это можно написать в 85 строчках кода (https://habr.com/post/349022)

Ты правда считаешь, что резолв обзерваблов прост?

Само объявление компонента объектом - это хуево

Это приватное апи. Тебе никто не позволял так компонент объявлять.

Ты правда считаешь, что резолв обзерваблов прост?

что значит резолв обзерваблов?

Это приватное апи. Тебе никто не позволял так компонент объявлять.

Мне написали про объявление компонента объектом, я сказал, что имел в виду не объявление. Ты-то куда ~_~

что значит резолв обзерваблов?

Может биндинги мобх и не магия но то как он работает внутри - это магия.

Вообще, мне в таких случаях хочется говорить, что проблема не в том, какое решение приняли разработки реакта, а в том, что сам язык — говно и как ни выкручивайся, удобно не получится. Даже с этими грёбаными хэндлерами, которые либо на каждом рендере заново создаются, либо докидывают в код бойлерплейта

Опять вброс про mobx) Извини но я не могу не ответить) Мне кажется заявлять что mobx такой плохой потому что в нем куча "магии" сродни тому как не зная что такое промисы и имея только знакомство с коллбеками заявлять что async/await является магией. В этой "магии" есть минус только в том что она немного повышает порог вхождения (как и async/await которые требуют знания промисов) но зато после того как разобрался с mobx все становится прозрачным и ничем не хуже редакса в плане предсказуемости 1) Mobx не заставляет "обливаться говном декораторов". Декоратор это просто синтаксический сахар который экономит две строчки кода. Хочешь не используй декораторы и вместо одной строчки class SomeStore { @observable user = ""; ... } пиши 3 строчки class SomeStore { _user = observable(""); get(){ return this._user.get() } set(val){ this._user.set(val) } ... } 2) А если уже геттеры и сеттеры жс каждутся магией то mobx не заставляет их использовать - это всего лишь синтаксический сахар обращения к полям, хочешь не используй но вместо простой записи <div> task's folder name: {this.props.task.project.folder.name} </div> придется на каждое обращение к полям добавлять .get() вызовы <div> task's folder name: {this.props.task.get().project.get().folder.get().name.get()} </div> 3) Если работа самого mobx кажется "магией" то на хабре есть несколько постов (https://habr.com/users/bgnx/posts) с подробным объяснением как он работает. А основной механизм работы mobx можно даже в объяснить в одном предложении: При оборачивании компонента observer-хокком mobx врапит рендер-функцию компонента и при вызове присваивает в глобальную переменную (а при выходе из функции возращает предыдуще значение) ссылку на инстанс этого компонента чтобы при обращении к observable-сторам (которые создаются через observable(val)) через .get()-вызов происходило добавление компонента из глобальной переменный в массив подписок этого observable-стора и потом при изменении значения стора через .set("") происходил вызов рендера всех компонентов из массива подписок Правда надо заметить что в mobx в массив подписок добавляется не сам компонент а объект реакции который уже будет вызывать сайд-эффект обновления компонента, а computed это некий подпид реакции который вместо сайд-эффекта перевычисляет функцию (добавляя таким образом мемоизацию) и решает глитчи (лишние вычисления). Но даже все это можно написать в 85 строчках кода (https://habr.com/post/349022)

а теперь отвечу на твоё сообщение. Что я называю магией и неочевидностью вот делаешь ты где-то this._data.value = 1 и в большом проекте ты можешь даже не знать, что у тебя обновилось больше одного стора. А чего разрешение циклических обновлений? сколько там раз обновляется, а потом просто останавливается обновление не завершившись и оставив данные в неконсистентном состоянии?

Может биндинги мобх и не магия но то как он работает внутри - это магия.

Как он работает изнутри я описал выше в одном предложений. И в тех статьях на хабре все пошагово объясняется через написание аналога mobx-а.