а тут дело не в источнике. У тебя контекст - это key-value, то есть вполне возможен конфликт, даже с типизацией

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

ну и вообще SelectListItem'ы могут быть pure functions

Ребят, никто не видел годный бойлерплейт с mobx, где есть серверный рендеринг?

mobx намного проще redux'а

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

да) Но я подумал, пришло время спросить в конфе :D

MobX не нужен когда есть rx и most

mobx намного проще redux'а

Да, Дэн Абрамов говорил, что mobx фреймворк для тех кто не осилил redux

Да, Дэн Абрамов говорил, что mobx фреймворк для тех кто не осилил redux

он не так говорил )

Он это имел ввиду

для тех, кто устал от редукса

нет

да, согласен с Владимиром

и кстати он в своем твитере оценил http://www.apollostack.com/ , говорит норм штука

MobX не нужен когда есть rx и most

а что на счет Cycle.js?

а где можно посмотреть на тэстировку для react?

а где можно посмотреть на тэстировку для react?

что именно интересно?

https://github.com/redux-observable/redux-observable

Имеет ли смысл в папке с компонентом делать package.json файл в котором указан main или просто делать index.js файл и все? А то встречаю оба варианта

Это отдельный компонент или компонент в каком то проекте?

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

Ребят, появилась проблема с Object.assign на некоторых андроид девайсах и вот в чем вопрос, у меня в некоторых нод модулях используются они, но получается что они сами не используют никакой полифил для этого, стоит ли мне прям у себя в приложении просто использовать полифил или просто настроить транспиляцию бабелем object.assign в нод модулях?

глобально полифил

вот у меня тоже такое ощущение, правда я все еще считаю *flux* все тем же mv*

мне вот показалось, что mobx это какой-то разворот к mvc или чему-то подобному

нет? действительно показалось?

что именно интересно?

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

Ребят, появилась проблема с Object.assign на некоторых андроид девайсах и вот в чем вопрос, у меня в некоторых нод модулях используются они, но получается что они сами не используют никакой полифил для этого, стоит ли мне прям у себя в приложении просто использовать полифил или просто настроить транспиляцию бабелем object.assign в нод модулях?

бабел оттранспилит в core-js, который добавит полифил

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

я предпочитаю делать index.js

enzyme глянь для тестов

глобально полифил

есть ли причина?

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

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

если файл называется не index.js(x), то он же не будет подключен через require(‘Some/Component’)? и плевать, есть там package.json или нет

есть ли причина?

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

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

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

если файл называется не index.js(x), то он же не будет подключен через require(‘Some/Component’)? и плевать, есть там package.json или нет

А если компонент экспортируется в index.js, то будет подключен

если есть возможность лучше юзать нативный assign

технически флакс - это тот же mvc, так что неясно, где тут разворот.

если файл называется не index.js(x), то он же не будет подключен через require(‘Some/Component’)? и плевать, есть там package.json или нет

я через import подключаю, он учитывает package.json

не согласен, что тот же

вопрос только про устройство связи с M

если есть возможность лучше юзать нативный assign

а полифил разве так не делает?

да

именно так

поэтому лучше полифил, чем транспилить

какая разница?

это будет понифил, или как он там называется

когда module.exports = Object.assign || function()...

я через import подключаю, он учитывает package.json

ого! вот это поворот, спасибо. это фишка вебпака?

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

А если компонент экспортируется в index.js, то будет подключен

index.jsx: import Component from ‘./Component.jsx’ export default Component ?

index.jsx: import Component from ‘./Component.jsx’ export default Component ?

export * from './Component.jsx'

export * from './Component.jsx'

ага, так лучше) а зачем делать такой прокси-файл? почему не сразу в идексе? для удобства в редакторе, навигации в гитхабе и т.п.?

index.jsx: import Component from ‘./Component.jsx’ export default Component ?

когда делаем import './component/App' будет взят по умолчанию index.js если есть package.json с main: 'App' то будет взят файл ./component/App/App.js

Я про вот этот подход https://github.com/kriasoft/react-starter-kit/tree/master/src/components/Feedback

так а зачем создавать два файла вместо одного index.js?

ага, так лучше) а зачем делать такой прокси-файл? почему не сразу в идексе? для удобства в редакторе, навигации в гитхабе и т.п.?

ну например может быть ситуация с кучей компонентов где-то в приложении: import { Foo, Bar } from '../components' в components директории в index.js export { Foo } from './Foo' export { Bar } from './Bar'

я вообще предпочитаю делить таким образом App.jsx App - Header.jsx - Main.jsx - ...

Вот тут описано почему лучше каждый компонент хранить в отдельной папке: https://github.com/kriasoft/react-starter-kit/blob/master/docs/react-style-guide.md#separate-folder-per-ui-component

Add package.json file into each component's folder.

а чем index.js не подходит?

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

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

++

с отдельной папкой и pages.json можно использовать разные версии для сервера и клиента при желании, автоматом разрулится что брать Component.browser.js или Component.server.js

ERROR: S client not available

не, отдельно index.js

вот папка, внутри компонент, подкомпоненты, а наружу торчит index.js с export default и хелперами, если нужно

я думаю index.js тоже нормально подходит для реэкспорта

browser.js/server.js разруливается webpack конфигом

index.js тоже подходит для реэкспорта, но теряется фича о которой я написал выше с browser.js и server.js

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

а как же css?

переводы?

или речь идет о компонентах провайдерах? src/containers/TodoList.js в котором только работа со стором

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

Я храню каждый компонент в своей папке)

Правда проекту еще далеко до реального)

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

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

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

а сколько у тебя компонентов?

Ребят, никто не сталкивался с такой проблемой: на некоторых встроеных браузерах на андроидах и в ие 10- почему-то все фишки ES6 отваливаются и тупо приложуха крашится

у нас большой энтерпрайз проект. Так как у 80% комопнентов нет отдельных стилей и картинок, мы не делаем под каждый папку. Если нужны стили, то называем файл так же как компонент и храним в той же директории. BlahBlah.js BlahBlah.scss

пока все устраивает

около 90 те что в src/components, плюс специфичные для страниц компоненты лежат рядом с самой страницей src/routes/store/[index.js, StorePage.js, ShoppingСart.js]

На реакт проекте пока 25 компонентов и 10 контейнеров, на рабочем (не реакт) 100+ компонентов общих на несколько проектов и на каждом штук 20-30 контейнеров + все оборачивается в компоненты страниц

А кто-нибудь совмещает разделение на Containers, Components, Pages с nested structure?

я просто думал проблема в Object.assign, но в бабеле же есть встроенный полифил на это все

В проекте с которым приходится сейчас работать полный пиздец. Где require, где import, где-то код на ES3, где-то jsx, а где-то import from '../../../../../Whatever.jsx' и библиотека со сторонними контролами снаружи лежит, а не в node_modules. В свободное время приходится это говнище приводить потихоньку в божеский вид

В проекте с которым приходится сейчас работать полный пиздец. Где require, где import, где-то код на ES3, где-то jsx, а где-то import from '../../../../../Whatever.jsx' и библиотека со сторонними контролами снаружи лежит, а не в node_modules. В свободное время приходится это говнище приводить потихоньку в божеский вид

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

> Kich import from '../../../../../Whatever.jsx' вот от этого конечно тоже хочется избавиться, пока думаю как, может алиасы использовать

а как же css?

а стили собирать отдельно - плохая практика? я про less main.less - components - component1.less - component2.less - ...

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

ну хотя бы к единому виду привести

pages это уровень перед containers?

а стили собирать отдельно - плохая практика? я про less main.less - components - component1.less - component2.less - ...

если при этом хранить их в отдельной папке, то да, странно

а стили собирать отдельно - плохая практика? я про less main.less - components - component1.less - component2.less - ...

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

а стили собирать отдельно - плохая практика? я про less main.less - components - component1.less - component2.less - ...

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