собрать все возможные комбинации в классы, я так понимаю?

собрать все возможные комбинации в классы, я так понимаю?

Да!

Это же дешевле через classnames делать

И еще – как импортировать переменные? (cssnext) Через @value плагин?

Других способов нет?

Я об этом: https://github.com/css-modules/postcss-modules-values

Это же дешевле через classnames делать

думаю, легче всё-таки два-три класса написать, чем создавать кучу классов вида .ActiveSmallLoadingSecondary

думаю, легче всё-таки два-три класса написать, чем создавать кучу классов вида .ActiveSmallLoadingSecondary

Это понятно что легче, концепция рушится. Раз пятый берусь разобраться в нем за последний год – никаких изменений, проблемы все те же, кейсов больше не стало, все говорят об одном и том же, что все хорошо, а это не так.

ну первоочередная проблема-то в изолировании имён, а композиция — так, плюшки)

Хорошо, имена изолировали, как быть с переменными?

https://github.com/css-modules/postcss-modules-values Так?

а сейчас как импортируешь? через @import?

Сейчас sass, хочу изолировать переменные.

Не найду информации как импортировать правильно перменные из cssnext: https://github.com/MadLittleMods/postcss-css-variables

(только через @import "./vars.css")

https://github.com/css-modules/postcss-modules-values Так?

по-моему этот плагин не имеет отношения к импорту и чем тебя не устраивает @import "./vars.css"?

Хочу import red as someprefix-red from colors

Где можно нормальный date range найти?

Этот плагин как раз такое и позволяет.

Хочу import red as someprefix-red from colors

мне кажется для такого лоадер нужен специальный, а не плагин для переменных

мне кажется для такого лоадер нужен специальный, а не плагин для переменных

Возможно, надо еще думать как все это организовывать.

Где можно нормальный date range найти?

Попробуй этот - довольно гибкий календарь https://github.com/gpbl/react-day-picker Вот пример для диапазона дат http://www.gpbl.org/react-day-picker/examples/#range

ага, вроде что нужно, спасибо

Коллеги, кто знает как тестировать компоненты, обернутые в react-router? Mocha, поднимаем в phantomJS

history фейковый подсунуть

const history = createMemoryHistory(location);

Бля, я уж думал

Увидел имя Sergey, решил, что это @chicoxyzzy пьяный с набережной вещает

?

?

А в тестах оборачивать в роутинг?

BeerJS официально самая крупная конференция разработчиков в стране. Реакт ты можешь и не знать, но BeerJS'ом быть обязан

а в каком случае данные нужно хранить в редаксе, а в каком нет?

Конкретизируй =)

я с коллегами прочитал мануал по редаксу и нашел там типа такие штуки: dispatch({ type: 'LOAD_POSTS_REQUEST', userId }) теперь у нас каждая фича выглядит монструозно, с кучей редьюсеров и экшенов. Вопрос, зачем писать экшены и редьюсеры, если например данные по загрузке нужны только внутри компонента (показать спиннер)

для соблюдения основного смысла единого стейта и тестирования

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

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

это полезно с разных точек зрения

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

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

зато упрощает поддержку :)

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

надо просто мозги немного в другую сторону повернуть

зато упрощает поддержку :)

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

через 2-3 итерации это будет монстр, а не компонент

надо просто мозги немного в другую сторону повернуть

Я вот пытаюсь) Только плюсов кроме релизиозности в его вел-ву Редасу не вижу)

ну только что назвал тебе плюс

почему монстр?

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

появляются неявные зависимости

контроллер - это бизнес-логика

данные фетчатся каждый раз при маунте компонента? а что если потребуется два таких на странице?

данные фетчатся каждый раз при маунте компонента? а что если потребуется два таких на странице?

вот когда их понадобится два, тогда и нужен редакс :)

не

с флаксом тоже самое

тут смысл в том, что данные отдельно, вью отдельно

особенно с точки зрения тестирования

ты сможешь получить компонент в любом состоянии с минимумом магии если все проходит цикл флакса/редакса

ну а как всякие material-ui тестируются

ты сможешь получить компонент в любом состоянии с минимумом магии если все проходит цикл флакса/редакса

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

внутри ui иметь стейт на мой взгляд норм

т.е. только бизнес-логика должна лежать в сторе, верно?

не вижу много бойлепрейт кода

сделай себе миддлвары/экшн генераторы

ERROR: S client not available

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

которые будут кидать pending состояния сами

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

остается только в реакте их рендрить

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

редьюсеры ничего не должны обрабатывать)

я имею ввиду я сам не пишу return {...state, penging: true}

за меня это делает небольшая обертка, которую я написал 1 раз

у тебя pending один на все приложение?

нет конечно

на 1 редьюсер

редьюсеры можно друг в друга вкладывать

а можешь поподробнее написать?

function createReducer(initialState, actionHandlers) { return (state = initialState, { type, payload, error, meta }) => { const handler = actionHandlers[type]; if (!handler) { return state; } if (error) { return { ...state, error: payload, pending: false }; } if (meta) { if (meta.pending) { return { ...state, pending: true, error: false }; } } return { ...state, error: false, ...handler(payload, state, meta), pending: false }; }; } export default createReducer;

const user = createReducer({ authorized: false, registerPassed: false, form: {} }, { [USER_LOGIN]: onLogin, [USER_LOGOUT]: onLogout, [USER_REGISTER]: onRegister, [USER_DESTROY]: onLogout, [USER_FETCH]: onFetch, [USER_UPDATE]: onFetch });

function createReducer(initialState, actionHandlers) { return (state = initialState, { type, payload, error, meta }) => { const handler = actionHandlers[type]; if (!handler) { return state; } if (error) { return { ...state, error: payload, pending: false }; } if (meta) { if (meta.pending) { return { ...state, pending: true, error: false }; } } return { ...state, error: false, ...handler(payload, state, meta), pending: false }; }; } export default createReducer;

а meta.pending в middlewares ставится/снимается?

function createReducer(initialState, actionHandlers) { return (state = initialState, { type, payload, error, meta }) => { const handler = actionHandlers[type]; if (!handler) { return state; } if (error) { return { ...state, error: payload, pending: false }; } if (meta) { if (meta.pending) { return { ...state, pending: true, error: false }; } } return { ...state, error: false, ...handler(payload, state, meta), pending: false }; }; } export default createReducer;

блин, почему то у меня до сих пор была логика switch/case type, матчится на другие вещи в action не думал

Парни, а кто чем логирование на клиенте и сервере реализует? Есть альтернативы bunyan?

я логгер изоморфный писал год назад гдето

для изоморфногореакт аппа

а я два

но у решений типа bunyan есть плюсы

можно из коробки подключать разные коннекторы

но им только на сервере же

изоморфно же :)

что-то поменялось значит :)

я на https://github.com/brophdawg11/JsChannels

запилил.. и канал открывал client->server или server->server

)

а воще еси bunyan с клиента писать может то больше ничего не нужно

на другом конце можно разные ридеры втыкать и редиректить

в splunk или куда угодно