Беспокоят лишние 100+ кб, ради пары тройки компонент

Ну смотря какая стратегия. Если планируется постепенное переползание на реакт, то это неизбежно

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

кстати, кто как относится к библиотечке ractivejs ?

вроде не хуже реакта, но легковесна

вот, есть обрезанный реакт. Только там нету серверного рендеринга, ну, и еще пару фич https://github.com/Lucifier129/react-lite

за то 20 кб

Обычно каждый редьюсер отвечает за свой кусочек сторы. И каждый умный компонент тоже юзает свой кусочек.

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

не делает магии у меня webpack с реактом. просто перезагрузка страницы без сохранения стейта :/ у меня стейт правда на урл завязан так что в принципе что-то оно выводит но не совсем та магия которую хотелось бы. поставил react-hmre preset. походу все таки что-то не так я делаю :/ и так конечно прикольно, но хотелось бы чтобы совсем по красоте чтобы пахало

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

думаю, таких каналов уже достаточно

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

все равно будут заходить в профильные и писать туда тоже

думаю, таких каналов уже достаточно

Именно по React-стеку?

все равно будут заходить в профильные и писать туда тоже

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

думаю, таких каналов уже достаточно

a не подскажешь пару каналов ? Кроме тех, что от хабра

я не искал. а в профильном по реакт-стеку, вангую, что будет полтора человека

это и есть профильный канал по реакт-стеку с четырьмя сотнями участников :)

я не искал. а в профильном по реакт-стеку, вангую, что будет полтора человека

Ну, ок можно по фронтенду, но боюсь тогда они будут теряться в бесконечных angular/jquery-вакансиях

Ну, ок можно по фронтенду, но боюсь тогда они будут теряться в бесконечных angular/jquery-вакансиях

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

Нужные строгие правила для оформления предложения, dev-ua/jobs вполне себе нормально существует

подробное описание вакансии с вилкой зарплат

про определенный формат вкансий плюсую.

Пытались делать такие группы. Они не живут.

Вот интересные слайды про Relay и HTTP API в частности с недавнего #PiterPy: https://www.slideshare.net/mobile/MaxKlymyshyn/piterpy-2016-parallelization-aggregation-and-validation-of-api-in-python

Привет всем! Подскажите, кто как решает проблему хранения token-ов в Redux приложении? Проблема такая: есть app с ssr + сторонний сервер с данными, после логина приходит jwt токен. Сейчас он лежит в cookie. Во многих redux-примерах token пихают в state, но так как это isomorphic приложение state у нас прямо на клиенте лежит в INITIAL_STATE. А теперь вопрос, как тут дела обстоят с sequrity? Подскажите какой-нибудь the right way! Благодарю за помощь, комьюнити!

Подскажите, кто как решает проблему хранения token-ов в Redux приложении? - я в localStorage храню

LocalStorage не подойдет

С сервере к нему доступ не получить, это же клиент

кроме cookie по-моему нет вариантов больше

Да, хранить token в cookie норм вариант, но мне нужен этот токен для некоторых запросов к API. Также советуют использовать httpOnly для cookie, чтобы из js к нему доступ нельзя было получить, но как тогда этот токен то для запросов использовать?)

Нужео httpOnly и а на беке только читать куки

Вот неплохая статья по этому поводу, может кому будет полезна https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

можно не использовать httpOnly, но тогда с csrf могут быть проблемы

Так же как и сессиями работает все

а можно хранить токен в куках с httpOnly и дублировать его либо в initialState либо в локалсторадже

но это геморно, конечно

А зачем дублировать, это не секьюрно

LocalStorage не вариант

а httpOnly readble на клиенте, да?

я просто не в курсах

нет же

нет не читаемый

я пьян

Лучше вообще не читать куки на клиенте это потенциально дыра в секюрити

А если запросы не всегда через сервер идут?

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

проксировать с сервера на апи тоже не гуд

Так как быть, господа?)

а в чем проблема держать в сторе его?

проксировать

Проблема в том, что у тебя будет токен на клиенте лежать

в этом по-моему и задача заключается)

А sequrity где?)

а кто его может получить то? из стора то?

Все что есть на клиенте, мы можем получить...

Токен секрентый или это токен пользователя?

Если это секретный ключ к апи то храни его на севере и проксируй на нужное тебе апи

если это просто пользовательская куку то у тебя от гугла того же в браузеере куча кук, твоих собственных и они httpOnly и в логи не срутся

JWT токен пользователя

От твоего серева?

Твоей апишки

ERROR: S client not available

да

по токену получаю данные для пользователя

Ну смотри ты же сервером отдаешь данные только которые может видеть пользователь? так вот если ты куку будешь хранить в httpOnly то сторонние чуваки не смогут ее засеч в логах твоего сервера и тем самым ее достать

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

Но что он с ней сделает? она же его, то есть данные из этого ключа нового ему ничего не дадут, так ведь?

Вопрос закрыт?

@AGambit как я понял можно хранить в стэйте и не париться? так?

так ты будешь слать куку на клиент (так как ты ее увидишь в js)

Либо я чего не допонял)

и ее потенциально можно перехватить

В куках httpOnly подругому

так как зачем тебе хранить куку на фронте?

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

Понял. Спасибо!

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

привет socket.io

О, ребят, скоро будет хорошо: https://github.com/gaearon/react-hot-boilerplate/pull/61

что именно будет хорошо?

babel-plugin-react-transform deprecated

все плохо

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

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

К сокетам мы еще придем, пока что необходимо решение без их использования

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

Куки не нужны.

И апишка должна через токен в хидерах работать

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

Для доступа к API

Можно уже и куку юзать, современные андройд и айос это понимают. Хотя хедер тоже ок вариант)

кука это тоже хедер, есличо))