помогите мне придумать проект где реакт просто необходим

Pomodoro Timer + ToDo сделай:D

как вариант)

если "просто необходим" то помодоро таймер и тодо он не нужен

Существует ли решение для создания компонента, его интеграции со стейтом приложения и подписки на событие сервера? Я поясню: Допустим, весь фронтенд получает данные по своей инициативе с сервера только при загрузке и при действии пользователя. В остальных случаях обновления фронтенда происходят по инициативе сервера. Обновления приходят по вебсокетам. Допустим, если у нас отрендерился компонент "Публикация", то его контейнер сразу автоматически подписал стейт на события обновления содержания поста (автор отредактировал, удалил, изменил настройки доступа), лайки и комментарии. Если компонент исчезает со страницы, то стейт отписывается от соответствующих событий. В итоге, мы получаем магию, при которой приложение само контролирует, на что и в какой момент времени оно подписано.

В общем народ я решил проблему с ресурсами через настройки Jest moduleNameMapper

никакие хуки не помогли

"jest": { "bail": true, "verbose": true, "testPathDirs": [ "__tests__" ], "moduleNameMapper": { "\\.(css|less)$": "identity-obj-proxy", "\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$": "<rootDir>/fileTransformer.js" } },

вот так вот получилось

Это нужно, в package.json прописать

Существует ли решение для создания компонента, его интеграции со стейтом приложения и подписки на событие сервера? Я поясню: Допустим, весь фронтенд получает данные по своей инициативе с сервера только при загрузке и при действии пользователя. В остальных случаях обновления фронтенда происходят по инициативе сервера. Обновления приходят по вебсокетам. Допустим, если у нас отрендерился компонент "Публикация", то его контейнер сразу автоматически подписал стейт на события обновления содержания поста (автор отредактировал, удалил, изменил настройки доступа), лайки и комментарии. Если компонент исчезает со страницы, то стейт отписывается от соответствующих событий. В итоге, мы получаем магию, при которой приложение само контролирует, на что и в какой момент времени оно подписано.

звучит как редакс)))

хм, интересно

звучит как редакс)))

Это может быть и с редаксом, и без.

Народ а я вот попробовал MobX и заметил что я просто перестаю обращаться к this.state реакта :)))))

что означают значки с "B" возле свойств? При наведении курсора он выдаёт хинт configurable enumerable, что является неправдой)

Это может быть и с редаксом, и без.

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

звучит как редакс)))

Суть в том, что при рендере компонента серверу посылается событие socket.emit('subscribe', { toWhat }), а при уничтожении — socket.emit('unsubscribe', { fromWhat }).

Дадада.

Может есть уже велик?

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

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

И не только. Он должен реализовывать абстракцию и над компонентом, и над сокетом.

просто сделать unrenderable component, и включать его в каждый нужный тебе контейнер

И не только. Он должен реализовывать абстракцию и над компонентом, и над сокетом.

ну это все уже детали

мне кажется, тебе лучше самому такое написать

я не встречал готовых велосипедов (хотя я и не смотрел специально)

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

Хотя... Здесь больше работы для бэкенда. Оборачивать контейнер — это лишнее. Мы можем просто запрашивать у сервера подписки через экшны.

Существует ли решение для создания компонента, его интеграции со стейтом приложения и подписки на событие сервера? Я поясню: Допустим, весь фронтенд получает данные по своей инициативе с сервера только при загрузке и при действии пользователя. В остальных случаях обновления фронтенда происходят по инициативе сервера. Обновления приходят по вебсокетам. Допустим, если у нас отрендерился компонент "Публикация", то его контейнер сразу автоматически подписал стейт на события обновления содержания поста (автор отредактировал, удалил, изменил настройки доступа), лайки и комментарии. Если компонент исчезает со страницы, то стейт отписывается от соответствующих событий. В итоге, мы получаем магию, при которой приложение само контролирует, на что и в какой момент времени оно подписано.

по-моему ты просто описал нормальные компоненты-контейнеры Так и должно быть: компонент появился в доме — подписался. Компонент dismounted — отписался.

по-моему ты просто описал нормальные компоненты-контейнеры Так и должно быть: компонент появился в доме — подписался. Компонент dismounted — отписался.

Речь идёт не о подписке на стейт фронтенда, а о подписке на события с сервера. Просто сервер рассылает события по каждому сокет-соединению индивидуально.

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

Речь идёт не о подписке на стейт фронтенда, а о подписке на события с сервера. Просто сервер рассылает события по каждому сокет-соединению индивидуально.

а в чем разница?..

а в чем разница?..

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

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

Да, всё правильно.

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

но ты же сам написал до этого, что компонент подписывается, когда отрендерился

Короче. У нас есть стейт. Контейнер соединяет его с компонентом. Стейт общается с сервером по вебсокетам. Т.е. серверу приходит каждый диспатч (или не каждый), и сервер сам может диспатчить в стейт (это уже по факту реализовано). Контейнер при монтировании компонента диспатчит в стейт "хочу подписаться на такие-то события", мидлвэр стейта пересылает запрос подписки в сокет-соединение серверу. Клиент подписан. Произошло нужное событие на сервере — событие в сокет клиенту, диспатч в стейт, изменения в стейте, обновление компонента, профит.

Т.е. никаких централизованных персонифицированных механизмов общения с сервером.

> Стейт общается с сервером по вебсокетам. -- через мидлвару или как? имхо это несколько мутное решение

> Стейт общается с сервером по вебсокетам. -- через мидлвару или как? имхо это несколько мутное решение

Да. Всё очень круто работает. И код чище в разы.

> Стейт общается с сервером по вебсокетам. -- через мидлвару или как? имхо это несколько мутное решение

Я вибираю, какие экшны может слушать сервер, а какие — нет. И всё.

А серверу становится доступен диспатч каждого клиента.

А серверу становится доступен диспатч каждого клиента.

Meteor?

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

Meteor?

Мне не понравилось.

Logux?

Logux?

А вот об этом я не слышал.

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

Можно просто сделать миксин с mount и unmount, не?

Так. Я сейчас понял, что это нужно реализовать на уровне мидлвэра к сокету.

Т.е. возможность задать интерфейс подписки клиента на события сервера, а на сервере — медиатор, через который проходят все события.

Тогда можно экшны редакса привязыватьк командам подписки.

Тебе явно нужна уточка возле компьютера))

Пардон?

Пардон?

https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D1%83%D1%82%D1%91%D0%BD%D0%BA%D0%B0

Лол

Ну, наверн.

Не, ну я же правильно сделал, что написал сюда. =)

О, кстати. Пользуясь случаем. Очень похожая система у нас, как описал Котяй, разве что без веб сокетов, fetch api тянет джейсоны. Нужно получить некоторые метаданные с сервера, которые будут нужны потом большинству компонент. Где это лучше вчего сделать?

Без подписки в каждом редьюсере, это как то нарушает DRY

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

ну, отдельный кусок стора, в смысле

Да, я понял, идея вполне норм. Я только не очень понимаю, как потом передать эту дату дальше по дереву

Ладно, спасибо, буду копать дальше)

что означают значки с "B" возле свойств? При наведении курсора он выдаёт хинт configurable enumerable, что является неправдой)

Boolean?

Boolean?

а, да, похоже :)) хинт всё равно неверный (

Да, я понял, идея вполне норм. Я только не очень понимаю, как потом передать эту дату дальше по дереву

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

1. https://ant.design/components/ 2. http://dev.office.com/fabric#/components 3. https://react-mdl.github.io/react-mdl/components/ Какие ещё хорошие библиотеки компонентов есть для React сегодня?

ERROR: S client not available

http://react-toolbox.com/

Норм, есть ещё что-нибудь?

Если простенькое - http://elemental-ui.com/

Норм, есть ещё что-нибудь?

От парней из Palantir http://blueprintjs.com/

чет там хистори даже нет

в элементале

на самом сайте)

чо там в графкл?

подписки будут?

От парней из Palantir http://blueprintjs.com/

юзаем на внутренних проектах. нраица

@vyorkin наверное сможет поподробнее о впечатлениях рассказать

От парней из Palantir http://blueprintjs.com/

Да, отлично)

но вообще выбирали из-за ts в первую очередь

Итого, полный список: 1. https://ant.design/components/ 2. http://dev.office.com/fabric#/components 3. https://react-mdl.github.io/react-mdl/components/ 4. https://react-toolbox.com/ 5. http://elemental-ui.com/ 6. http://blueprintjs.com/ 7. http://react.semantic-ui.com/introduction/

но вообще выбирали из-за ts в первую очередь

Когда уже от TS откажетесь? :)

когда жс сдохнет очевидно

Когда бухать перестанут

От парней из Palantir http://blueprintjs.com/

А как же семантикюай?

А как же семантикюай?

И то же!

А как же семантикюай?

Но там toggle не очень – http://react.semantic-ui.com/addons/radio

от мелкософта ничо так

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

оно не рендерится(

див пустой(

Link вместо a используй

так там же return после console.log

Link вместо a используй

что ты имеешь в виду? как тег?

оберни a в ()

Ах, да И оберни jsx код внутри map в скобки и на ту же строку, что и return перенеси начало