это его единственная выгода?)

ну если придрочиться преставлять state всего приложения в виде таких простых неглубоких объектов - выгода довольно очевидна

но вообще, если он и правда просто реализует pure-render-mixin - то да

Все) Понял) Спасиииибо большое)

Подскажите плз, у меня компоненты разбиты по папкам, в которых лежат файлы index.jsx, стили. Вопрос заключается в том, чтобы импортить их без указывания в пути "index.jsx". import List from './components/List' вместо import List from './components/List/index.jsx' Я где-то читал, что это можно настроить в webpack, мб кто-то сталкивался?

Можно создать в папке компонента фаил package.json, в котором указать: { "main": "./compName.jsx" } Можно в папку с компонентом кидать index.js, откуда уже ссылаться на прод\дев версии компонента.

Лол. Чятик не подгрузился и я поиграла в некро =(

Можно создать в папке компонента фаил package.json, в котором указать: { "main": "./compName.jsx" } Можно в папку с компонентом кидать index.js, откуда уже ссылаться на прод\дев версии компонента.

Второй вариант мне нравится больше, спасибо. Но я настроил webpack через resolve.

ребята простой вопрос: есть такая структура <main> <one/> <two/> </main> внутри two есть кнопка, по нажатию должен происходить экшн в компоненте one. Торможу, как это сделать красиво? без всяких рефов и вынесений через них нужных функций

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

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

на сколько я понимаю ref нужен для того, чтоб читать данные какого-нибудь компонента/тега, а то что есть возможность оттуда что-то выносить и использовать это уже извращение, мое имхо

я вообще стараюсь через ref ничего не делать

на сколько я понимаю ref нужен для того, чтоб читать данные какого-нибудь компонента/тега, а то что есть возможность оттуда что-то выносить и использовать это уже извращение, мое имхо

ref обычно для неуправляемых компонент, то есть данные лежат внутри DOM самих контролов, а value/onChange позволяет точно управлять состоянием контрола без необходимости трогать DOM

и вообще можно хранить это состояние в том же сторе того же Redux

пффф... ref - ссылка(reference) на инстанс, событие - именно событие, а не состояние. То есть вызов ref.danceWithBareAss() - вполне нормально и никем не запрещено... зачем выдумывать себе лимиты использования библиотеки? Типа я не буду использовать $.closest потому что там две буквы s в названии...

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

и там ref недоступен

плюс держать ВЕСЬ стейт приложения может быть довольно убобным

например его можно целиком одной строчкой запихать в localStorage

если там конечно циклических ссылок нет

так я и не говорю про стейт, вопрос был в вызове метода при клике. Клик - это эвент, кликнуто - состояние. а функции, никто не запрещает тебе юзать hoc ^^

а при чём тут клик?

внутри two есть кнопка, по нажатию должен происходить экшн в компоненте one.

аааа

внутри two есть кнопка, по нажатию должен происходить экшн в компоненте one.

А что значит "происходить экшн в компоненте one"? Это как-то неправильно. Экшены должны же вызываться из компонент, а не обрабатываться. Точнее могут конечно обрабатываться (как правило тривиально), но чтобы обрабатывать экшн соседнего компонента - это как-то странно.

Вообще, я считаю, что в идеальном мире построение UI ведётся с помощью чистой функции. Это по идее должно невероятно облегчать отладку. Причём желательно, чтобы эта функция была от одного аргумента - от стейта. При использовании React + Redux и без использования стейтов компонент так и происходит.

Только по моему мнению, иммутабельность стейта в Redux - это лишнее требование.

Только по моему мнению, иммутабельность стейта в Redux - это лишнее требование.

иммутабельность всегда хорошо

иммутабельность всегда хорошо

Иммутабельность запрещает циклические ссылки между объектами (иначе любое изменение приведет к перегенерации всего состояния). Почему-то всегда сравнивая mobx и redux забывают про главную киллер-фичу mobx - возможность хранить в состоянии ссылки между объектами, которые могут указывать друг на друга (циклические ссылки). Например у объекта юзера есть массив todos объектов todo и у каждого объекта todo есть ссылка обратно на объект юзера. Эта простая концепция позволяет по данной схеме сущностей моделировать состояние одним единственным образом и хорошо масштабируется какое бы количество сущностей и one-to-many связей там не было бы. И решает много проблем с моделированием деревьев в редаксе

Иммутабельность запрещает циклические ссылки между объектами (иначе любое изменение приведет к перегенерации всего состояния). Почему-то всегда сравнивая mobx и redux забывают про главную киллер-фичу mobx - возможность хранить в состоянии ссылки между объектами, которые могут указывать друг на друга (циклические ссылки). Например у объекта юзера есть массив todos объектов todo и у каждого объекта todo есть ссылка обратно на объект юзера. Эта простая концепция позволяет по данной схеме сущностей моделировать состояние одним единственным образом и хорошо масштабируется какое бы количество сущностей и one-to-many связей там не было бы. И решает много проблем с моделированием деревьев в редаксе

Правда для запихивания в localStorage такую штуку придётся по хитрому сериализовать/десериализовать в JSON

Правда для запихивания в localStorage такую штуку придётся по хитрому сериализовать/десериализовать в JSON

https://github.com/WebReflection/circular-json

https://github.com/WebReflection/circular-json

проблема решена

скажите есть примеры UI либ под react с inline edit полями

я тут накатал свое но боюсь косячно все очень ((

https://material.uplabs.com/

может кому интересно будет

сайт как источник вдохновения

powerpoint material design template with animations :0

А что значит "происходить экшн в компоненте one"? Это как-то неправильно. Экшены должны же вызываться из компонент, а не обрабатываться. Точнее могут конечно обрабатываться (как правило тривиально), но чтобы обрабатывать экшн соседнего компонента - это как-то странно.

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

Вообще, я считаю, что в идеальном мире построение UI ведётся с помощью чистой функции. Это по идее должно невероятно облегчать отладку. Причём желательно, чтобы эта функция была от одного аргумента - от стейта. При использовании React + Redux и без использования стейтов компонент так и происходит.

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

Только по моему мнению, иммутабельность стейта в Redux - это лишнее требование.

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

Иммутабельность запрещает циклические ссылки между объектами (иначе любое изменение приведет к перегенерации всего состояния). Почему-то всегда сравнивая mobx и redux забывают про главную киллер-фичу mobx - возможность хранить в состоянии ссылки между объектами, которые могут указывать друг на друга (циклические ссылки). Например у объекта юзера есть массив todos объектов todo и у каждого объекта todo есть ссылка обратно на объект юзера. Эта простая концепция позволяет по данной схеме сущностей моделировать состояние одним единственным образом и хорошо масштабируется какое бы количество сущностей и one-to-many связей там не было бы. И решает много проблем с моделированием деревьев в редаксе

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

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

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

Всем привет! https://getstorybook.io/ пользовался кто-нить?

Ребят, все привет. Не кидайтесь помидорами, я новичек. Подскажите пожалуйста как на кнопку повесить переход на другую страницу прописанную в роутах? Или может подскажите как лучше сделать авторизацию. Т.е. нажал ввел данные, отправил на сервак, получил ответ - вошел. На скрине мой текущий код, но в консоли браузера: TypeError: Cannot read property 'push' of undefined. Что я делаю не так? Авторизация проходит, проблема в переходе на страницу при успешной авторизации

хм, а куда сообщение делось? Повторюсь. подскажите пожалуйста как сделать корректный переход на страницу при успешной авторизации. Сейчас в браузере выдает TypeError: Cannot read property 'push' of undefined. ну и критика любая приветствуется, т.к. новичек и только вилваюсь

this.props.router

Ребята, подскажите пожалуйста есть массив a = [ {foo: 5, ....}, {foo: 10, ....}, {foo: 20, ....} ] как можно получить сумму всех foo?

Пишешь функцию для сложения элементов массива, передаешь в неё a.map((el) => el.foo)

Ребята, подскажите пожалуйста есть массив a = [ {foo: 5, ....}, {foo: 10, ....}, {foo: 20, ....} ] как можно получить сумму всех foo?

.

Ребята, подскажите пожалуйста есть массив a = [ {foo: 5, ....}, {foo: 10, ....}, {foo: 20, ....} ] как можно получить сумму всех foo?

eval(a.map(b => b.foo).join('+'))

а reduce не проще?..

понятно, спасибо большое

eval(a.map(b => b.foo).join('+'))

Лол

Вообще, редьюс как раз для таких целей очень хорошо подходит.

Хотя, мне крайне импонирует вариант с eval :D

думал может есть что-то как в рельсах a.sum(:foo)

a.reduce((prev, cur) => prev + cur.foo, 0)

eval(a.map(b => b.foo).join('+'))

?

R.pipe(R.map(R.prop('foo')), R.sum) — вот так еще можно

a.reduce((prev, cur) => prev + cur.foo, 0)

да уже вычитал после сообщения от @dartess

ERROR: S client not available

спасибо большое

?

Хохотач

Раз уж я осмелился написать, подскажите пожалуйста, "getInitialState" ведь должен идти раньше, чем "render"? Или я что-то путаю?

сейчас же не стильно писать getInitialState, надо через свойство класса начальный state объявлять или this.state в конструкторе на худой конец

Раз уж я осмелился написать, подскажите пожалуйста, "getInitialState" ведь должен идти раньше, чем "render"? Или я что-то путаю?

Насколько мне известно, использовать getInitialState не рекомендуется. Вместо этого, следует в конструкторе задать начальное значение state.

Спасибо) Я пока не знаю, что стильно, что нет.

Иммутабельность запрещает циклические ссылки между объектами (иначе любое изменение приведет к перегенерации всего состояния). Почему-то всегда сравнивая mobx и redux забывают про главную киллер-фичу mobx - возможность хранить в состоянии ссылки между объектами, которые могут указывать друг на друга (циклические ссылки). Например у объекта юзера есть массив todos объектов todo и у каждого объекта todo есть ссылка обратно на объект юзера. Эта простая концепция позволяет по данной схеме сущностей моделировать состояние одним единственным образом и хорошо масштабируется какое бы количество сущностей и one-to-many связей там не было бы. И решает много проблем с моделированием деревьев в редаксе

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

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

есть у меня компонент, юзается на двух страницах, как часть большой страницы и отдельная страница на которой он один, юзаю react-helmet чтобы тайтлы ставить и react-router для роутинга, есть какие-нибудь способы не ставить тайтл когда он включен в страницу и ставить когда он один на странице, кроме как костыльно проверять локейшен?

все равно костыль получится ж)

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

С чего это вдруг? Перидоически сохраняем стейт в JSON (с разрешением циклических зависимостей) и пихаем эту строку в массив. Да, не самая оптимальная штука, но мы ведь об отладке говорим?

все равно костыль получится ж)

ну да, наверное лучшим способом будет создать еще один компонент, в котором будет только helmet и этот компонент и в роутер пихнуть его

Поделитесь опытом, кто как делает таблицы под моб. разрешение экрана?

Игнорируем его

Поделитесь опытом, кто как делает таблицы под моб. разрешение экрана?

Можно в контейнер с overflow: auto засунуть, чтобы появлялся скролл на маленьких экранах.

Игнорируем его

Неплохооо, весьма

Неплохооо, весьма

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

Так что выходов из ситуации масса!

Я просто пока обошелся overflow-x scroll, просто интересно, кто как решает такую проблему

Я просто пока обошелся overflow-x scroll, просто интересно, кто как решает такую проблему

я иду к дизайнеру/ специалисту по ui/ux и говорю давай размеченные макеты на мобилку

Поделитесь опытом, кто как делает таблицы под моб. разрешение экрана?

скролл внтури таблицы

ну и главное сделать злобное лицо чтоб сомнений не осталось

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

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

Понятно) спасибо, просто до этого не работал с таблицами для моб. почти

смотрел пару решений на различных css-tricks

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

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

Та же история, только 720