ссылки включающие коммиты

А если по теме вопроса?)

вот такой вариант указывает на ветку которая может поменяться

Хорошее замечание на самом деле

не вижу ничего плохого передавать экшены сверху

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

Давно так используете?

не сразу, но пришли к этому полгода назад как раз из-за удобства переиспользования и общей внятности большой code base

+ в этом real-world example не хватает redux-actions

redux-act смотрели?

А как разделяете action ID?

Ребят посоветуйте какой бойлерплейт на yeoman, чтобы был TypeScript, Sass-lib, и может какой BrowserSync

Никакой

UPDATE_USER_NAME? Или вида namespace user.updateName? Или что то ещё?

Бойлерплейты не нужны

UPDATE_USER_NAME? Или вида namespace user.updateName? Или что то ещё?

1

не сразу, но пришли к этому полгода назад как раз из-за удобства переиспользования и общей внятности большой code base

ап

)

Бойлерплейты не нужны

Ну если я спрашиваю – то значит мне понадобился, правильно?

https://www.npmjs.com/package/redux-actions предпочел вместо react-act

Нет

Ты просто ещё не понял что они не нужны

++ bulma, purecss

Я бутстрап беру. У него бибилиотека виджетов самая полная. Но у меня говностартапы - дизайна нет

https://www.npmjs.com/package/redux-actions предпочел вместо react-act

++

Ты просто ещё не понял что они не нужны

У меня нету сейчас времени сетапить самому

npm i —save-dev libsass …etc?

https://www.npmjs.com/package/redux-actions предпочел вместо react-act

Просто так случилось или чем обосновано с точки зрения архитектуры API/пакета?

Всё, проехали. Выбесил

не сразу, но пришли к этому полгода назад как раз из-за удобства переиспользования и общей внятности большой code base

А какое соглашение используете для actions? Одноуровневые const-like вида UPDATE_USER_NAME? Или вложенные неймспейсы вида user.updateName, user.profile.updateName? Или что то ещё?

Просто так случилось или чем обосновано с точки зрения архитектуры API/пакета?

цель была простая - избавиться от констант и следовать конвенции flux standart actions

одноуровневые UPDATE_USER_NAME, но с redux-actions выбор этой конвенции не играет особой роли

Просто так случилось или чем обосновано с точки зрения архитектуры API/пакета?

Задачи наши эти две библиотеки решают одинаково хорошо, но в у первой намного больше комьюнити

Да, это понятно, но не было ли у вас проблем в итоге с тем, что action_id разростался совсем?

С точки зрения масштабирования вроде namespace-like выглядит более гибко. Оно прекрасно ложится на GraphQL и RESTful API: createAction('session.user.profile.updateFirstName', value => validate(value, rules)) Что может вызвать POST /api/v1/session/user/profile или соответствующую мутацию для GraphQL.

Плюс сюда же можно версию API добавить легко (это может показать космосом, но представим себе большое Enterprise-решение).

согласен, но у нас rpc и это неактуально

@denisizmaylov до какого числа на митап подавать доклад?

а если абстрагироваться от генерирования посредством redux-action/redux-act, а рассматривать классический подход, то как вы храните/импортируете константы? - экспортируете каждую константу отдельно - экспортируете один объект с константами?

31 мая митап / 21 мая прогон / 16 мая дедлайн по докладам

Ок

а если абстрагироваться от генерирования посредством redux-action/redux-act, а рассматривать классический подход, то как вы храните/импортируете константы? - экспортируете каждую константу отдельно - экспортируете один объект с константами?

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

Плюс tree shaking

мне объект нравится тем, что не надо указывать необходимые константы в импорте, хотя можно конечно импортировать как import * as constants

Посмотри в сторону Ant.design

Посмотрел. Всё очень хорошо, но не срослось.

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

если dateTimeRangePicker нужен, то лучше ant, а так те же яйца

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

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

+

@DenisIzmaylov

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

Рассматриваем пару площадок, в том числе Digital October

Но плюс всегда рады приглашениям на новые интересные большие площадки, способные принять 100-150 чел

чет в яндексе не хватило места)

Так-то да) Не успели вовремя закрыть регу

а я не успел во вермя приехать и стоял в дверях :D

И в зале на 90 человек пришлось укомпоноваться уютно 130-150 :)

Но можно было занять себе место "после антракта"))

так и сделал))

к счастью все любят поесть

;D

На митапах это святое

?

я тут экспериментирую с TouchBar + Electron

http://www.giphy.com/gifs/l0IyoP9cKGbye0mCk

https://gist.github.com/LestaD/69963787daf1dcad055cb9ac11292046

в React-стиле

согласен, но у нас rpc и это неактуально

Резюмируя, относительно обсуждения, текущие рекомендации для крупных 3R-проектов: 1. Использовать redux-actions / redux-act, отказавшись от констант для action ID 2. Именовать action ID в формате namespace-нотации вида session.user.profile.updateFirstName 3. Вынести весь state из компонентов приложения в Redux Store, оставив state только для универсальных UI-компонентов / TODO: есть ли проблемы с производительностью в этом случае? 4. Обработчики событий определять через ES Class Properties Что упущено? /сс @evgenyrodionov @imrajdee @ZeroBias @syabro @fjfalcon @ppavle @klimashkin @gaearon

Даня тут?

О, кстати, вышел. Но это понятно, ему надо на английском языке сосредоточиться.

В твиттере аудитория больше)

ERROR: S client not available

1) да 2) на любителя, у меня @@cem/newsletters/load/list/started или что-то типа этого 3) да 4) в чём смысл?

4 — чтобы не биндить

Нейминг конвеншнс и другие стандарты. Сегодня на курсе зарубались с одним человеком, у которого стиль кода отличается от моего. Мой — общепринятый, потому что у меня была команда и единственный разумный стайлгайд это тот, которого придерживается большинство в коммьюнити. Стиль кода сродни художественному — все похуй на ваш авторский взгляд, главное — читаемость. В джс это стандарт от Эйрбнб, в CSS/HTML — от mdo, автора Бутстрапа. Но, конечно, вручную это проверять — ад (Кофемания зовёт, зачем тратить время и ебать друг другу голову за буквы?), поэтому в нормальных проектах есть eslint и stylelint, а в самых охуенных — prettier, я о нём уже говорил.

3. Нет

Стараюсь не использовать redux если без этого можно обойтись

Нейминг конвеншнс и другие стандарты. Сегодня на курсе зарубались с одним человеком, у которого стиль кода отличается от моего. Мой — общепринятый, потому что у меня была команда и единственный разумный стайлгайд это тот, которого придерживается большинство в коммьюнити. Стиль кода сродни художественному — все похуй на ваш авторский взгляд, главное — читаемость. В джс это стандарт от Эйрбнб, в CSS/HTML — от mdo, автора Бутстрапа. Но, конечно, вручную это проверять — ад (Кофемания зовёт, зачем тратить время и ебать друг другу голову за буквы?), поэтому в нормальных проектах есть eslint и stylelint, а в самых охуенных — prettier, я о нём уже говорил.

Жду появления траста «Родионов и партнёры» ?

Жду появления траста «Родионов и партнёры» ?

В смысле гей-клуб?)

Резюмируя, относительно обсуждения, текущие рекомендации для крупных 3R-проектов: 1. Использовать redux-actions / redux-act, отказавшись от констант для action ID 2. Именовать action ID в формате namespace-нотации вида session.user.profile.updateFirstName 3. Вынести весь state из компонентов приложения в Redux Store, оставив state только для универсальных UI-компонентов / TODO: есть ли проблемы с производительностью в этом случае? 4. Обработчики событий определять через ES Class Properties Что упущено? /сс @evgenyrodionov @imrajdee @ZeroBias @syabro @fjfalcon @ppavle @klimashkin @gaearon

что за 3R?

Rodionov Rodionov Rodionov

Или React Redux Router

React Relay Router

React Redux Relay Router

Это уже другая была бы история

Rodionov Rodionov Rodionov

Лол

Ы

Резюмируя, относительно обсуждения, текущие рекомендации для крупных 3R-проектов: 1. Использовать redux-actions / redux-act, отказавшись от констант для action ID 2. Именовать action ID в формате namespace-нотации вида session.user.profile.updateFirstName 3. Вынести весь state из компонентов приложения в Redux Store, оставив state только для универсальных UI-компонентов / TODO: есть ли проблемы с производительностью в этом случае? 4. Обработчики событий определять через ES Class Properties Что упущено? /сс @evgenyrodionov @imrajdee @ZeroBias @syabro @fjfalcon @ppavle @klimashkin @gaearon

Зачем 4. пункт?

Чтобы без this.handleClick = this.handleClick.bind(this) в конструкторе

Зачем 4. пункт?

ап

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

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

Это и есть best-practice

Интересно

А ещё что-нибудь можно добавить?

Эй псс, есть кто?)

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

Приехали, а биндинг — это не пересоздание функции?

А потом удивляются, почему на собеседованиях простые вещи спрашивают)

С козырей зашёл. ?

Парни а как лучше сделать подгрузку данный? Пока додумался так: проходят все фильтры, и срабатывает функция которая по частям выводит массив. Текущая страница отмечается в стейте. componentDidMount вешаю document.addEventListener('scroll',this._someFunc). А в самой функции, той что выводит частями, при превышении количества страниц снимаю событие с докумена. Это норм, или есть лучше решение?

Приехали, а биндинг — это не пересоздание функции?

> Так что байндить надо в конструкторе вручную и вырезать этот блок при сборке для ssr.

> Так что байндить надо в конструкторе вручную class SomeClass { state = { value: 0 } handler = () => this.state.value++ } Транспилируется в class SomeClass { constructor() { this.state = { value: 0 }; this.handler = () => this.state.value++; } } Теперь всё то же самое но руками: class SomeClassWithBind { constructor() { this.state = { value: 0 }; this.handler = this.handler.bind(this) } handler() { return this.state.value++; } }

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