Ребят, подскажите какую либу использовать для Drag-n-Drop в react ?

React-DnD не работает :) не получилось его завести просто даже для примера посмотреть, хотя либа достойная

Все он работает

React-DnD не работает :) не получилось его завести просто даже для примера посмотреть, хотя либа достойная

А что именно нужно? В ReactDnD есть примеры, посмотри их

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

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

потому решил спросить есть ли либа другая которая билдится нормально. Тако ощущение что автор react-dnd давно уже не поддерживает в актуальном состоянии :)

Поддтвердите или опровергните :)

Эмм

Билдить либу чтоб посмотреть примеры

Зачем

Можно же npm i react-dnd сделать

Очевидно, речь о примерах из репы dnd

https://github.com/gaearon/react-dnd/tree/master/examples

Ну тогда лучше разобраться почему не удалось примеры запустить

А не искать другую либу

Ребят, такой вопрос, как мне получить данные из файла .json из componentDidMount? Использую fetch, но сколько я не пытался, никак данные не вытягиваются

fetch('./config.json') .then((res) => console.log(res)) }

Ребят, такой вопрос, как мне получить данные из файла .json из componentDidMount? Использую fetch, но сколько я не пытался, никак данные не вытягиваются

http://myjson.com

Спасибо, буду пробовать

http://myjson.com

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

а, все, понял

кароче кто тут с редаксом еще не обосрался, кидайте ссылочки на свои проекты, я хочу посмотреть экшены/редусеры :)

Kupibilet.ru — страница поиска

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

Когда-нибудь будет нормально...

Знакомо) Сам пилю подобное и про многое верю, что скоро сделаю лучше :)

Wow! Реально? Никого из Твери здесь нет? :)

@wop_wops , кажется, оттуда.

Доброе утро

Ребят, такой вопрос, как мне получить данные из файла .json из componentDidMount? Использую fetch, но сколько я не пытался, никак данные не вытягиваются

его можно просто заимпортить, если в конфиге есть json-loader, причем тут fetch

Народ! Еще есть вопрос: Кто нибудь писал тесты на компоненты, которые используют сторонние либы такие как jQuery и ему подобные?

Народ! Еще есть вопрос: Кто нибудь писал тесты на компоненты, которые используют сторонние либы такие как jQuery и ему подобные?

а как это выглядит?

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

Ну типа внутри используется какая нибудь либа из пакета bootstrap

Просто интересно как можно в этой ситуации Full render тесты производить, c подгрузкой этих либ

а есть тут адепты MobX ?

Ну мне нравится mobx и не нравится redux. Я приведу несколько объективных причин из за которых по умолчанию mobx будет быстрее а с редаксом примерно одинаковая производительность будет только если напишем дополнительно еще гору кода. Пример - есть примитивный компонент class Task extends React.Component { render(){ <div> <div>{task.id}</div> <div>{task.title}</div> </div> } } В мобиксе достаточно только добавить @observable в редаксе нужно написать еще обычно стену кода в mapStateToProps под компонентом. 1) если использовать древовидную стуктуру в редаксе (например состояние приложения по схеме appState = {currentPage: {title: '', boards: [...{id: 'board1', tasks: [....{id: 'task1', ...}]}],}} то у нас при любом изменении таска будет рендеритmся не только компонента таска но и все родительские компоненты 2) чтобы такого не было надо использовать нормализованный подход и хранить состояние в виде таблиц и хеша по айдишникам appState = {users: {user1: {id: 'user1',..}, boards: {'board1': {id: 'board1'}}, tasks: {task1: {id: 'task1'...}}}} но получаем те проблемы с вытаскиванием данных по айдишникам каждый раз и код в mapStateToProps многократно увеличивается 3) чтобы добиться равной производительности нужно не только хранить в нормализованном виде все состояние но еще и маппить данные в mapStateToProps непосредственнно по свойствам - но так не делают а обычно пишут connect((state, props)=>{ return { task: state.tasks[propsId] } })(Task) но тогда компонент будет ререндериться когда изменится любое из его свойств независимо от того что он рендерит всего два свойства (id и title) в отличие от mobx и для того чтобы производительность была сравнима нам нужно по-честному выписывать все свойства connect((state, props)=>{ return { id: state.tasks[propsId].id, title: state.tasks[propsId].title, } })(Task) 4) но все равно каждый раз когда в приложении возникло любое изменение то редакс будет прогонять все mapStateToProps абсолютно всех компонентов чтобы посмотреть изменился результат после маппинга чтобы перерендерить соответствующий компонент. А mobx будет рендерить только те компоненты который в данный момент отрендерились (а не абсолютно все) и будет проверять только те свойства которые потребовались при последнем рендере и только на тех местах которые зависят от изменившегося свойства (так просто работает резолвинг динамического дерева зависимостей в mobx) Вот даже сам Dan Abramov писал - https://twitter.com/dan_abramov/status/719973322453348352 5) mobx использует мутабельный подход и просто меняет свойства на месте, в редаксе на каждое изменение нужно не просто сгенерировать новый объект но также и все зависимые от этого другие объекты и вверх до самого корневого объекта состояния. Из-за этого в состоянии невозможно хранить ссылки между объектами потому что нужно будет перегенерировать новые объекты всех зависимостей а это рекурсирвно (в случае ссылок) приведет к перегенрации всего состояния на каждое малейшее изменение Даже если не брать пункты выше касательно производительности - есть еще 2 самые главные проблемы удобства которые решает Mobx 1) В redux-е неудобно работать с объектами у которых есть между собой ссылки (а это любые приложения отличные от todo-app где количество сущностей со связями one-to-many больше одного) - потому что приходится все данные нормализировать в виде хеша айдишников по таблицам и потом на каждый чих вытаскивать по айдишнику нужный объект из центрального состояния. Вот пример - сравните две строчки в обработчике клика: node.parent.children.filter(node=>...)[0] dispatch(getNodeById(node.parentId)).children.map(childId=>dispatch(getNodeById(childId)).filter(node=>...)[0] первая строчка это mobx (или любая другая библиотека обзерваблов как например CellX, deriableJS, Reactive.js, $jin.atom) и мы можем в обработчиках сразу обращаться к связям как к объектам по ссылке , а вторая строчка это редакс и мы вынуждены доставать каждый раз по айдишнику через диспатч thunk-а объект из общего состояния и этот подход очень мусорит код 2. Одна из самых неприятных вещей - необходим

а есть тут адепты MobX ?

ость постоянного маппинга свойств в mapStateToProps для того чтобы redux знал какие компоненты обновлять. Растет целая стена кода из маппинга объектов из состояния по айдишникам из пропсов компонента.В mobx не требуется никакой маппинг вообще.Просто в render-е пишем любые свойста объекта и любые вложенные свойства на любой глубине хоть даже node.parent.user.nodes[2].nextSibling.children[3].user.firstName - mobx через обертки геттеров над свойствами сам поймет какие компоненты и какие свойства используют и в дальнейшем при любом изменении будет обновлять только нужные компоненты

ость постоянного маппинга свойств в mapStateToProps для того чтобы redux знал какие компоненты обновлять. Растет целая стена кода из маппинга объектов из состояния по айдишникам из пропсов компонента.В mobx не требуется никакой маппинг вообще.Просто в render-е пишем любые свойста объекта и любые вложенные свойства на любой глубине хоть даже node.parent.user.nodes[2].nextSibling.children[3].user.firstName - mobx через обертки геттеров над свойствами сам поймет какие компоненты и какие свойства используют и в дальнейшем при любом изменении будет обновлять только нужные компоненты

?

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

1

Хотя зависит от того, как именно ты деплоишь

пока никак

=)

Если у тебя есть CI, то очевидно 1

CI нету

Если ты вручную через scp закидываешь, то локально собираешь и потом копируешь на сервер, это самое дешевое

Но 2 подходит когда ты один в команде

1 когда несколько людей

Потому что можно роллбек сделать, по бранчам деплоить, етц

надо будет подумать насчет CI, туда же еще тесты прикрутить можно

спасибо

ситуацию понял

на gitlab есть free CI и приватные репы

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

надо себе ставить

у меня есть парочка инстансов spivot.space -- ce git.howto.cards -- ee

Ну мне нравится mobx и не нравится redux. Я приведу несколько объективных причин из за которых по умолчанию mobx будет быстрее а с редаксом примерно одинаковая производительность будет только если напишем дополнительно еще гору кода. Пример - есть примитивный компонент class Task extends React.Component { render(){ <div> <div>{task.id}</div> <div>{task.title}</div> </div> } } В мобиксе достаточно только добавить @observable в редаксе нужно написать еще обычно стену кода в mapStateToProps под компонентом. 1) если использовать древовидную стуктуру в редаксе (например состояние приложения по схеме appState = {currentPage: {title: '', boards: [...{id: 'board1', tasks: [....{id: 'task1', ...}]}],}} то у нас при любом изменении таска будет рендеритmся не только компонента таска но и все родительские компоненты 2) чтобы такого не было надо использовать нормализованный подход и хранить состояние в виде таблиц и хеша по айдишникам appState = {users: {user1: {id: 'user1',..}, boards: {'board1': {id: 'board1'}}, tasks: {task1: {id: 'task1'...}}}} но получаем те проблемы с вытаскиванием данных по айдишникам каждый раз и код в mapStateToProps многократно увеличивается 3) чтобы добиться равной производительности нужно не только хранить в нормализованном виде все состояние но еще и маппить данные в mapStateToProps непосредственнно по свойствам - но так не делают а обычно пишут connect((state, props)=>{ return { task: state.tasks[propsId] } })(Task) но тогда компонент будет ререндериться когда изменится любое из его свойств независимо от того что он рендерит всего два свойства (id и title) в отличие от mobx и для того чтобы производительность была сравнима нам нужно по-честному выписывать все свойства connect((state, props)=>{ return { id: state.tasks[propsId].id, title: state.tasks[propsId].title, } })(Task) 4) но все равно каждый раз когда в приложении возникло любое изменение то редакс будет прогонять все mapStateToProps абсолютно всех компонентов чтобы посмотреть изменился результат после маппинга чтобы перерендерить соответствующий компонент. А mobx будет рендерить только те компоненты который в данный момент отрендерились (а не абсолютно все) и будет проверять только те свойства которые потребовались при последнем рендере и только на тех местах которые зависят от изменившегося свойства (так просто работает резолвинг динамического дерева зависимостей в mobx) Вот даже сам Dan Abramov писал - https://twitter.com/dan_abramov/status/719973322453348352 5) mobx использует мутабельный подход и просто меняет свойства на месте, в редаксе на каждое изменение нужно не просто сгенерировать новый объект но также и все зависимые от этого другие объекты и вверх до самого корневого объекта состояния. Из-за этого в состоянии невозможно хранить ссылки между объектами потому что нужно будет перегенерировать новые объекты всех зависимостей а это рекурсирвно (в случае ссылок) приведет к перегенрации всего состояния на каждое малейшее изменение Даже если не брать пункты выше касательно производительности - есть еще 2 самые главные проблемы удобства которые решает Mobx 1) В redux-е неудобно работать с объектами у которых есть между собой ссылки (а это любые приложения отличные от todo-app где количество сущностей со связями one-to-many больше одного) - потому что приходится все данные нормализировать в виде хеша айдишников по таблицам и потом на каждый чих вытаскивать по айдишнику нужный объект из центрального состояния. Вот пример - сравните две строчки в обработчике клика: node.parent.children.filter(node=>...)[0] dispatch(getNodeById(node.parentId)).children.map(childId=>dispatch(getNodeById(childId)).filter(node=>...)[0] первая строчка это mobx (или любая другая библиотека обзерваблов как например CellX, deriableJS, Reactive.js, $jin.atom) и мы можем в обработчиках сразу обращаться к связям как к объектам по ссылке , а вторая строчка это редакс и мы вынуждены доставать каждый раз по айдишнику через диспатч thunk-а объект из общего состояния и этот подход очень мусорит код 2. Одна из самых неприятных вещей - необходим

Есть код посмотреть какие практики ты считаешь полезными?

на gitlab есть free CI и приватные репы

ну сейчас там и лежит проектик

Есть код посмотреть какие практики ты считаешь полезными?

Кода пока нет, позже выложу болерплейт для mobx. Суть в моделировании сторов не в виде TodosStore где будет массив todo объектов (как часто показывают в примерах) а в виде моделирование связей между сущностями. Изначально у нас всегда есть сущность юзер - значит пишем class User {} и создаем единственный объект текущего юзера, дальше есть сущность Todo и пишем class Todo {} и вот тут уже появляется one-to-many связь между юзером и тодо. И тогда у юзера будет свойство todos = [] которое будет хранить массив объектов Todo класса а объект Todo класса в обязательном порядке должен хранить ссылку на юзера (todo = {id: '1', title: 'todo', user: user}) и только тогда нам достаточно передать в пропсах компоненту только один объект а всю остальную информацию этот компонент может получить сам путешествуя по состоянию через точки (node.parent.parent.firstChil.user) в рендере и обработчиках. И такой подход лучше подходит для разработки сложный приложений где много сущностей и связей чем redux

Вот кстати я раньше писал про это

ERROR: S client not available

Народ а что вы думаете по поводу того что redux пропагандирует какой-то "view driven design"? - когда мы начинаем разрабатывать исходя из того как данные отображаются на экране или должны отобразится после какого-то действия - получаем кучу всяких акшинов BUTTON_CLICKED , export const CHANGE_ACTIVE_USER_ID = 'CHANGE_ACTIVE_USER_ID'; export const CHANGE_CURRENT_TIME = 'CHANGE_CURRENT_TIME'; export const CHANGE_IS_MOBILE = 'CHANGE_IS_MOBILE'; export const CHANGE_MODAL = 'CHANGE_MODAL'; export const CHANGE_PATH = 'CHANGE_PATH'; export const CHANGE_PLAYING_SONG = 'CHANGE_PLAYING_SONG'; export const CHANGE_SELECTED_PLAYLISTS = 'CHANGE_SELECTED_PLAYLISTS'; export const CHANGE_WIDTH_AND_HEIGHT = 'CHANGE_WIDTH_AND_HEIGHT';и в редюсерах мы обрабатываем все это как потребности наших вьюх.Для маленьких приложений такой подход прекрасно работает но при попытке разработать что-то сложное получается месиво из акшинов TASK_ADDED, TASK_DELETED, TASK_COMPLETED, TASK_RECIEVED на каждый тип сущности когда совершенно логически и естественно хочется выделить все эти акшины в три вида ADD,UPDATE, DELETE и думать в контексте сущностей а не событий. А есть кажется другой подход который кажется называется domain driven design ("DDD"), - который говорит что всю бизнес-логику мы должны сначала разрабатывать в чистом вакууме моделируя сущности как объекты и связи между ними и обрабатывать все изменения состояния в этих моделях через изменения самих объектов (ADD, UPDATE, DELETE). И только потом уже спускаться к отображению на компонентах и вьюхах, будь то мобилки или обычные сайты. То есть бизнес-сущностей может быть совсем немного - юзер, борд, пост, картика, комментарий а вот разнообразного количества того как это все должно отображаться, обновляться в компонентах вот это уже может быть бесконечное количество, но главное что сущности и бизнес-логика сущностей и связей (one-to-many, many-to-many) и совершенно не меняется, меняется только различная привязка и обработка этих данных только по требованию самих компонентов Я думаю второй подход лучше маштабируется при разработке сложных приложений

А как по опыту?

Первый подход и второй, какой лучше?

DDD конечно. Я у себя все сущности (классы User, Post, Comment) наследую от базового класса который добавляет методы create, update, delete, которые не только заботятся чтобы на обратных связях в onе-to-many добавить сслыки на объект (наример при создании Todo.create({title: 'todo', user: user} - нужно в объекте user также добавить ссылку на созданный тодо в массив todos) но и автоматически посылают запрос на сервер для сохранения.

В редаксе мало того что будет куча однотипных констант, редюсеров - add, update,delete, так еще и на каждую таблицу (users, posts, comments) И кроме этого еще куча акшинов на каждое действие для отсылки запросов на сервер

у вас какой-то не DDD, а CRUD с row data gateway, похожее на Active Record

ну можно группировать это как то

сигнатуру компонент покажи

Первый подход и второй, какой лучше?

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

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

DDD конечно. Я у себя все сущности (классы User, Post, Comment) наследую от базового класса который добавляет методы create, update, delete, которые не только заботятся чтобы на обратных связях в onе-to-many добавить сслыки на объект (наример при создании Todo.create({title: 'todo', user: user} - нужно в объекте user также добавить ссылку на созданный тодо в массив todos) но и автоматически посылают запрос на сервер для сохранения.

https://github.com/yelouafi/redux-saga/issues/70#issuecomment-181397054

у вас какой-то не DDD, а CRUD с row data gateway, похожее на Active Record

DDD в том плане что разработка бизнес-логики происходит не от потребностей компонент и то что они там хотят делать например CHANGE_SELECTED_PLAYLISTS, СOMPLETE_TODO а от моделирование domain-cущностей и связей между ними (отсюда и название domain driven design) и только уже где-то там в компонентах будет обновление нужной сущности - user.update({selectedPlaylist: playlist})

короче бизнес-логика в чистом вакууме обычно оборачивается вот чем. Приходит такой фронт к бекендеру, протягивает дизайн и говорит: мне вот тут нужен список постов по категориям, по три поста в категории, начиная с самых популярных, и по одному комменту на пост. А бек такой: ну сделай запрос на категории, потом для каждой категории по запросу сюда, и еще комменты отдельным запросом

тру стори

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

DDD в том плане что разработка бизнес-логики происходит не от потребностей компонент и то что они там хотят делать например CHANGE_SELECTED_PLAYLISTS, СOMPLETE_TODO а от моделирование domain-cущностей и связей между ними (отсюда и название domain driven design) и только уже где-то там в компонентах будет обновление нужной сущности - user.update({selectedPlaylist: playlist})

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

потому что разработчики изобретали код в вакууме

сигнатуру компонент покажи

вот к примеру делал форм-билдер https://jsbin.com/xeyumaxajo/edit?js,output, но тут мало сущностей чтобы раскрыть весь потенциал ddd подхода

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

DDD в том плане что разработка бизнес-логики происходит не от потребностей компонент и то что они там хотят делать например CHANGE_SELECTED_PLAYLISTS, СOMPLETE_TODO а от моделирование domain-cущностей и связей между ними (отсюда и название domain driven design) и только уже где-то там в компонентах будет обновление нужной сущности - user.update({selectedPlaylist: playlist})

ну вы же в курсе, что сущности отвязаны от инфраструктуры? Они не знают и никак не привязаны к персист слою, они переходят в разные состояния, а потом через unit of work например, какой-нибудь персистер собирает все изменения и в одной транзакции все это дело флушит. Во фронте вы встретитесь с проблемой транзакций(привет saga)

Bogdan а что там насчет SSR? в каком виде состояние будет приходить на клиент?

короче бизнес-логика в чистом вакууме обычно оборачивается вот чем. Приходит такой фронт к бекендеру, протягивает дизайн и говорит: мне вот тут нужен список постов по категориям, по три поста в категории, начиная с самых популярных, и по одному комменту на пост. А бек такой: ну сделай запрос на категории, потом для каждой категории по запросу сюда, и еще комменты отдельным запросом

это отнюдь не проблема бизнес-логики с подходом разработки через сущности и связи one-to-many. Это проблема того что бекенд не предоставляет апи для вытаскивания вложенных сущностей - например нужно собрать страницу где будут отображатся данные юзера, список постов и комментарии под постами - я пишу один-единстенный запрос на сервер GET /api/users/:id?merge=[{link: 'posts', c: [{link: 'comments'}]}] и на бекенде у меня один единственный контроллер (а не куча отдельных на каждый тип сущности как в рельсах например) вытащит по этой схеме юзера, все его посты а также все комментарии к этим постам одним запросом в базу

вот тебе надо для этого сделать язык запросов

jsonapi есть же

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

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

и запросов - типа по пальцам ног еще

ну нет, это только в мелких

Bogdan а что там насчет SSR? в каком виде состояние будет приходить на клиент?

Также как и обычно - сервер передает разметку и window.initialState = ... (вложенные объекты данных) а на фронде они инициализируются. Только момент в том что поскольку граф объектов через обычный джойсон сериализировать нельзя нужно просто заменить на CircularJSON.strignify()