я делаю типо свой сваггер

который есесна часто обновляется

(относительно часто)

и выглядит примерно так:

https://pastebin.com/VarnDqLq в initNews выскакивает ошибка с сообщением Network Error, как это исправить?

Коллеги, как правильно реализовать вызов функции внешней библиотеки, который происходит при обновлении стора? Компонент, в рендере которого вызов функции и return null ?

Коллеги, как правильно реализовать вызов функции внешней библиотеки, который происходит при обновлении стора? Компонент, в рендере которого вызов функции и return null ?

я ничего не понял

Коллеги, как правильно реализовать вызов функции внешней библиотеки, который происходит при обновлении стора? Компонент, в рендере которого вызов функции и return null ?

store.subscribe(library.fn)?

У меня есть внешняя библиотека - график. И по изменению данных в сторе (редакс сторе) я хочу передавать этой библиотеке эти изменённые данные.

в сторе selectedCurrency, а хочу после изменения этого значения вызывать chart.select(selectedCurrency)

Есть такая разметка <RadioGroup name="name"> <Radio /> <Radio /> </RadioGroup> как из RadioGroup прокинуть name в Radio?

в сторе selectedCurrency, а хочу после изменения этого значения вызывать chart.select(selectedCurrency)

чекать изменения в componentWillReceiveProps может

чекать изменения в componentWillReceiveProps может

так это же уже deprecated

Ну и вокруг чарта обертку сделать

мне не нужно DOM обновлять, а только функцию вызывать

const name = 'name' ... <RadioGroup name={name}> <Radio name={name}/> <Radio name={name}//> </RadioGroup>

Есть такая разметка <RadioGroup name="name"> <Radio /> <Radio /> </RadioGroup> как из RadioGroup прокинуть name в Radio?

вот

и я хочу вызывать эту функцию при изменении значения в сторе

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

Верю что как то можно в children прокинуть дальше

так это же уже deprecated

Ну componentDidUpdate тогда

Есть такая разметка <RadioGroup name="name"> <Radio /> <Radio /> </RadioGroup> как из RadioGroup прокинуть name в Radio?

<RadioGroup name="name"> {({ nameProp }) => ( <Radio name={nameProp} /> <Radio name={nameProp} /> )} </RadioGroup>

const RadioGroup = ({ name, children }) => children({ nameProp: name })

Ну componentDidUpdate тогда

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

у кого то были проблемы с <script type="text/babel"> Sublime код не хайлайтится внутри html?

у кого то были проблемы с <script type="text/babel"> Sublime код не хайлайтится внутри html?

@ide_ru

я тогда создам отдельный компонент и буду в рендере вызывать функцию

cпасибо

<RadioGroup name="name"> {({ nameProp }) => ( <Radio name={nameProp} /> <Radio name={nameProp} /> )} </RadioGroup>

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

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

лучше не надо

Кто нибудь воевал с высотой 100vh в мобильных браузерах?

Нельзя разве проитерироваться по детям и прокинуть дальше?

Нельзя разве проитерироваться по детям и прокинуть дальше?

можно но лучше этого избежать

Почему?

блин HOC'и это всё-таки очень неудобно! Возьмём упрощенный пример. Допустим у меня есть hoc withUser, который прокидывает два пропса: объект user и функцию updateUser Я пишу компонент: function UserButton({ user, ...htmlProps }) { return <button style={{ color: getFavColor(user) }} {...htmlProps}>hello, world</button> } export default withUser(UserButton); Кто-нибудь уже видит проблему? Проблема в том, что в ...htmlProps по-любому попадёт ненужный проп updateUser, которому на хтмл-элементе делать нечего. К сожалению, рекомпоузом эту проблему никак не решить. Вот такая попытка приведёт нас к новой проблеме: export default comspose( withUser, mapProps(props => ({ user: props.user }), )(UserButton); Проблема в том, что теперь в ...htmlProps не попадут вообще никакие дополнительно прокинутые пропсы Решение я вижу только одно, уродливое — написать некую omit функцию, которая будет знать про все возможные хтмл-пропсы. Но это отвратительно Единственное другое решение это знать о том, какие именно пропсы даёт withUser. Но в этом блин и проблема — мы этого не знаем и с ХОКами эту информацию легко не получить

Почему?

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

блин HOC'и это всё-таки очень неудобно! Возьмём упрощенный пример. Допустим у меня есть hoc withUser, который прокидывает два пропса: объект user и функцию updateUser Я пишу компонент: function UserButton({ user, ...htmlProps }) { return <button style={{ color: getFavColor(user) }} {...htmlProps}>hello, world</button> } export default withUser(UserButton); Кто-нибудь уже видит проблему? Проблема в том, что в ...htmlProps по-любому попадёт ненужный проп updateUser, которому на хтмл-элементе делать нечего. К сожалению, рекомпоузом эту проблему никак не решить. Вот такая попытка приведёт нас к новой проблеме: export default comspose( withUser, mapProps(props => ({ user: props.user }), )(UserButton); Проблема в том, что теперь в ...htmlProps не попадут вообще никакие дополнительно прокинутые пропсы Решение я вижу только одно, уродливое — написать некую omit функцию, которая будет знать про все возможные хтмл-пропсы. Но это отвратительно Единственное другое решение это знать о том, какие именно пропсы даёт withUser. Но в этом блин и проблема — мы этого не знаем и с ХОКами эту информацию легко не получить

не фильтруй пропсы, просто строй расширение и все вроде ок

не фильтруй пропсы, просто строй расширение и все вроде ок

"строй расширение" это что значит? Если не фильтровать, то говорю же, в ...htmlProps попадает лишнее

"строй расширение" это что значит? Если не фильтровать, то говорю же, в ...htmlProps попадает лишнее

откуда лишнее берется?)

откуда лишнее берется?)

дык по условию хок может много чего прокидывать. В данном примере он прокидывает неиспользуемый проп updateUser

дык по условию хок может много чего прокидывать. В данном примере он прокидывает неиспользуемый проп updateUser

ну я про это и спросил, откуда это функция сверху упала?)

ну я про это и спросил, откуда это функция сверху упала?)

я ж ответил уже, HOC её прокидывает оттуда же, откуда user пришёл

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

дык по условию хок может много чего прокидывать. В данном примере он прокидывает неиспользуемый проп updateUser

Я наверное что-то не уловил, но ведь ты сам заюзал хок, с ненужными тебе данными

Я наверное что-то не уловил, но ведь ты сам заюзал хок, с ненужными тебе данными

О том и речь. В этом проблема ХОКов, что так по-любому будет если только не писать хоки, которые строго по одному пропсу прокидывают. Но так никто не делает

Я наверное что-то не уловил, но ведь ты сам заюзал хок, с ненужными тебе данными

да с хоками есть такое дело, если не архитектить усиление, в итоге получится каша)

Подскажите какой щас самый модный способ писать стили для реакта?

Подскажите какой щас самый модный способ писать стили для реакта?

да сколько можно-то))

О том и речь. В этом проблема ХОКов, что так по-любому будет если только не писать хоки, которые строго по одному пропсу прокидывают. Но так никто не делает

причем тут хок?) Ты же в него прокинул излишнее данные?)

О том и речь. В этом проблема ХОКов, что так по-любому будет если только не писать хоки, которые строго по одному пропсу прокидывают. Но так никто не делает

Передавай в хок список того что он должен прокинуть

в цепочки усилитей нужно кидать данные которые нужны конечному компоненту

да сколько можно-то))

ты знаешь?

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

причем тут хок?) Ты же в него прокинул излишнее данные?)

да блин при том, что это стандартный подход)

compose( withGetData, withStyle, withAnimation )(component);

Подскажите какой щас самый модный способ писать стили для реакта?

Мы юзаем styled-components

блин HOC'и это всё-таки очень неудобно! Возьмём упрощенный пример. Допустим у меня есть hoc withUser, который прокидывает два пропса: объект user и функцию updateUser Я пишу компонент: function UserButton({ user, ...htmlProps }) { return <button style={{ color: getFavColor(user) }} {...htmlProps}>hello, world</button> } export default withUser(UserButton); Кто-нибудь уже видит проблему? Проблема в том, что в ...htmlProps по-любому попадёт ненужный проп updateUser, которому на хтмл-элементе делать нечего. К сожалению, рекомпоузом эту проблему никак не решить. Вот такая попытка приведёт нас к новой проблеме: export default comspose( withUser, mapProps(props => ({ user: props.user }), )(UserButton); Проблема в том, что теперь в ...htmlProps не попадут вообще никакие дополнительно прокинутые пропсы Решение я вижу только одно, уродливое — написать некую omit функцию, которая будет знать про все возможные хтмл-пропсы. Но это отвратительно Единственное другое решение это знать о том, какие именно пропсы даёт withUser. Но в этом блин и проблема — мы этого не знаем и с ХОКами эту информацию легко не получить

вот с рендер-пропсами такой проблемы нет

compose( withGetData, withStyle, withAnimation )(component);

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

вот с рендер-пропсами такой проблемы нет

а кто мешает юзать хок и рендер проп?)

compose( withGetData, withStyle, withAnimation )(component);

точно такая же проблема, каждый из этих хоков может прокидывать что-то, что конкретному component не нужно

а кто мешает юзать хок и рендер проп?)

да никто, рассуждаю ж прост

точно такая же проблема, каждый из этих хоков может прокидывать что-то, что конкретному component не нужно

Так не используй его для этого компонента, тебяж не заставляют)

я так с контекстом работаю, есть хок Provider, а внутри рендер проп)

ERROR: S client not available

Так не используй его для этого компонента, тебяж не заставляют)

так-то меня и ХОКи не заставляют использовать

но поговаривают что это круто, вон целый рекомпоуз написали

который не считая этой проблемы действительно удобный

точно такая же проблема, каждый из этих хоков может прокидывать что-то, что конкретному component не нужно

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

да никто, рассуждаю ж прост

да я тоже обсуждаю)

Хок это просто композиция в разрезе элементов реакта

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

да где же "ок"-то в твоём примере если какой-нибудь withGetData передаёт ненужный проп, тебе нужно чётко знать о том, какой именно

Не говорю уж про коллизию названий, это отдельная проблема из той же оперы

да где же "ок"-то в твоём примере если какой-нибудь withGetData передаёт ненужный проп, тебе нужно чётко знать о том, какой именно

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

Хок это просто композиция в разрезе элементов реакта

Хок — это откровенное наследование

Хок — это откровенное наследование

+

Хок — это откровенное наследование

это вообще как получается наследование?)

Хок — это откровенное наследование

Имеешь ввиду что хок может переопределить там пропсы?

блин HOC'и это всё-таки очень неудобно! Возьмём упрощенный пример. Допустим у меня есть hoc withUser, который прокидывает два пропса: объект user и функцию updateUser Я пишу компонент: function UserButton({ user, ...htmlProps }) { return <button style={{ color: getFavColor(user) }} {...htmlProps}>hello, world</button> } export default withUser(UserButton); Кто-нибудь уже видит проблему? Проблема в том, что в ...htmlProps по-любому попадёт ненужный проп updateUser, которому на хтмл-элементе делать нечего. К сожалению, рекомпоузом эту проблему никак не решить. Вот такая попытка приведёт нас к новой проблеме: export default comspose( withUser, mapProps(props => ({ user: props.user }), )(UserButton); Проблема в том, что теперь в ...htmlProps не попадут вообще никакие дополнительно прокинутые пропсы Решение я вижу только одно, уродливое — написать некую omit функцию, которая будет знать про все возможные хтмл-пропсы. Но это отвратительно Единственное другое решение это знать о том, какие именно пропсы даёт withUser. Но в этом блин и проблема — мы этого не знаем и с ХОКами эту информацию легко не получить

Не надо прокидывать в компонент то, что не надо прокидывать в компонент

это вообще как получается наследование?)

Хоки по очереди аффектят друг друга, точно так же как классы через extends

блин HOC'и это всё-таки очень неудобно! Возьмём упрощенный пример. Допустим у меня есть hoc withUser, который прокидывает два пропса: объект user и функцию updateUser Я пишу компонент: function UserButton({ user, ...htmlProps }) { return <button style={{ color: getFavColor(user) }} {...htmlProps}>hello, world</button> } export default withUser(UserButton); Кто-нибудь уже видит проблему? Проблема в том, что в ...htmlProps по-любому попадёт ненужный проп updateUser, которому на хтмл-элементе делать нечего. К сожалению, рекомпоузом эту проблему никак не решить. Вот такая попытка приведёт нас к новой проблеме: export default comspose( withUser, mapProps(props => ({ user: props.user }), )(UserButton); Проблема в том, что теперь в ...htmlProps не попадут вообще никакие дополнительно прокинутые пропсы Решение я вижу только одно, уродливое — написать некую omit функцию, которая будет знать про все возможные хтмл-пропсы. Но это отвратительно Единственное другое решение это знать о том, какие именно пропсы даёт withUser. Но в этом блин и проблема — мы этого не знаем и с ХОКами эту информацию легко не получить

Вот тебе omit ```mapProps(({ updateUser, ...rest }) => rest```

http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/

Хоки по очереди аффектят друг друга, точно так же как классы через extends

Эм так композиция это объединение функций, и они в любом случае будут афектить друг друга в какой-то последовательности

Эм так композиция это объединение функций, и они в любом случае будут афектить друг друга в какой-то последовательности

Не факт

Хоки по очереди аффектят друг друга, точно так же как классы через extends

compose( withWings, withСlutches, makeMonkey )(component);

({a, b, c})

А вот композиция

Найди три отличия

Вот тебе omit ```mapProps(({ updateUser, ...rest }) => rest```

а я уже сказал — с этим омитом проблема и делать его нельзя Мы просто напросто на этом месте прервём все дополнительные пропсы

смотри на примере выше) Какое наследование, если в конце я обезьяну делаю)

а я уже сказал — с этим омитом проблема и делать его нельзя Мы просто напросто на этом месте прервём все дополнительные пропсы

не понял

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

?

не понял

попробуй компонент использовать так <UserButton disabled={someBool} /> если у тебя там на пути mapProps, то disabled ты потеряешь

Наследование, это, грубо говоря, перетирание целевого объекта конструктором. ХОКи тоже самое делают