const noop = function () {};

Ну noop это для примера ))

Может быть тянет lodash, потому что где то в проекте используются еще импорты от него? Если нет, то можно и самому noop написать

const noop = () => {}; Прекрасный Javascript

сорри, он такой разный ☺

Я использую разные функции из него, но далеко не все. Вот и хочу обрезать их )

про сет стейт https://medium.com/@mweststrate/3-reasons-why-i-stopped-using-react-setstate-ab73fc67a42e#.zd33q1lkv

такая проблема асинхронного стейта решается банальным образом - вместо setState({selection: value}) пишем this.state.selection = value; this.forceUpdate(); и дальше в этом же методе уже можно что-то чекать с новым состоянием

такая проблема асинхронного стейта решается банальным образом - вместо setState({selection: value}) пишем this.state.selection = value; this.forceUpdate(); и дальше в этом же методе уже можно что-то чекать с новым состоянием

это антипатерн

почему?

lifecycle реакта ломается, как минимум

да и в статье и в доке есть про это )

NEVER mutate this.state

такая проблема асинхронного стейта решается банальным образом - вместо setState({selection: value}) пишем this.state.selection = value; this.forceUpdate(); и дальше в этом же методе уже можно что-то чекать с новым состоянием

Так есть же коллбэк у setState: this.setState(payload, () => { /* new this.state here */ });

`const noop = new Function`

new Function хитро ведет себя

в глобальном контексте функцию создает

хотя лучше конечно function noop() {}

тогда имя будет

в стеке

есть же еще

Function.prototype

lifecycle реакта ломается, как минимум

при this.forceUpdate() на самом компоненте не вызывается shouldComponentUpdate это да, но мне кажется проблема с этим небольшая потому что мы ведь в любом случае хотим чтобы он отрендерился. А вот что в доке говорят не мутировать то я этого не понимаю - сами придумывают проблемы с асинхронным состоянием и потом костыли для их решения. По хорошему вообще не нужно было придумывать никакого апи для хранения состояния - только пропсы и свободное хранения стейта где хочешь (например в виде this.property = value на компоненте) и для обновления разметки оставить единственный метод this.forceUpdate()

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

при this.forceUpdate() на самом компоненте не вызывается shouldComponentUpdate это да, но мне кажется проблема с этим небольшая потому что мы ведь в любом случае хотим чтобы он отрендерился. А вот что в доке говорят не мутировать то я этого не понимаю - сами придумывают проблемы с асинхронным состоянием и потом костыли для их решения. По хорошему вообще не нужно было придумывать никакого апи для хранения состояния - только пропсы и свободное хранения стейта где хочешь (например в виде this.property = value на компоненте) и для обновления разметки оставить единственный метод this.forceUpdate()

не только shouldComponentUpdate будет не рабочим. Как выше сказали, есть у setState коллбек, но это тоже так себе решение. Как сейчас сделано, меня устраивает.

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

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

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

Где можно прочитать, про эти изменения?

Где можно прочитать, про эти изменения?

https://www.facebook.com/notes/andy-street/react-native-scheduling/10153916310914590/

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

при this.forceUpdate() на самом компоненте не вызывается shouldComponentUpdate это да, но мне кажется проблема с этим небольшая потому что мы ведь в любом случае хотим чтобы он отрендерился. А вот что в доке говорят не мутировать то я этого не понимаю - сами придумывают проблемы с асинхронным состоянием и потом костыли для их решения. По хорошему вообще не нужно было придумывать никакого апи для хранения состояния - только пропсы и свободное хранения стейта где хочешь (например в виде this.property = value на компоненте) и для обновления разметки оставить единственный метод this.forceUpdate()

Здесь еще такая опасность, в facebook могут выпустить новую версию react, абослютно молча сделав в нем state компонента read-only (как это сейчас с props, мы не можем просто сделать this.props.someVal = 123), и справедливо полагая, что это никому ничего не должно сломать. К тому же, если вам так уж не нравится state, вы можете без проблем использовать this.property; this.forceUpdate()

Где можно прочитать, про эти изменения?

https://facebook.github.io/react/contributing/design-principles.html#scheduling

https://facebook.github.io/react/contributing/design-principles.html#scheduling

Спасибо, почитаю

https://github.com/kriasoft/react-starter-kit/blob/master/src/components/Html.js я охуеваю с этого стартеркита ебаного

https://github.com/kriasoft/react-starter-kit/blob/master/src/components/Html.js я охуеваю с этого стартеркита ебаного

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

О, наконец-то адекватный jsx в head’е, а не как это сделано в react-helmet :)

Встретился тут с одним неочевидным моментом при работе с редаксом после часа дебага - никогда не передавать в пропсах что-то отличное от айдишников компонентам-контейнерам которые сами что-то берут из стора потому что из-за того что редакс оповещает всех подписчиков в порядке который может не совпадать в порядком того как отрендерится дерево компонентов (например какой-то вложенный компонент оповестится и отрендерится раньше чем его родитель) то в пропсах окажется старый объект и все сломается

А зачем подписывать вложенные компоненты? Или имеется в виду подписка на что-то другое?

Оптимизация)

Встретился тут с одним неочевидным моментом при работе с редаксом после часа дебага - никогда не передавать в пропсах что-то отличное от айдишников компонентам-контейнерам которые сами что-то берут из стора потому что из-за того что редакс оповещает всех подписчиков в порядке который может не совпадать в порядком того как отрендерится дерево компонентов (например какой-то вложенный компонент оповестится и отрендерится раньше чем его родитель) то в пропсах окажется старый объект и все сломается

мочи все апдейты стора через unstable_batchedUpdates и будет тебе щастье

https://github.com/reactjs/redux/issues/1415

А зачем подписывать вложенные компоненты? Или имеется в виду подписка на что-то другое?

Ну да оптимизация - ведь основная идея редакса - благодаря иммутабельности и shouldComponentUpdate мы рендерим только те компонента которые при в mapStateToProps выдали несовпадающие с предыдущим вызовом данные. Если хранить подписывать только компонены верхнего уровня то на каждое обновление будет проход рендера по всему приложению. А в случае с tree view где могут быть тысячи вложенных нод будут тормоза

мочи все апдейты стора через unstable_batchedUpdates и будет тебе щастье

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

Привет всем. Ребят, подскажите, что не так в данной записи: constructor(props) { super(props); this.state = {open: false}; this.state = _getInitState(); }

все норм

1. ты прокидываешь props в super, но нигде props не используешь в constructor 2. _getInitState() может быть не определена 3. странно писать {open: false}, а потом переопределять state

Props используется дальше по компоненту

Спасибо

как лоадером загружать картинки из папки, которая не в src? Струтура: client …/src …/static сам вебпак работает в контексте /src а как в этом случае можно загрузить картинки из static?

как лоадером загружать картинки из папки, которая не в src? Струтура: client …/src …/static сам вебпак работает в контексте /src а как в этом случае можно загрузить картинки из static?

“в контексте” это в смысле context: path.resolve(__dirname, blahblah, ‘../src’) ? для лоадеров есть include/exclude, для настройки резолвинга eсть alias, вот крутой скринкаст по вебпаку https://learn.javascript.ru/webpack-screencast

https://github.com/kriasoft/react-starter-kit/blob/master/src/components/Html.js я охуеваю с этого стартеркита ебаного

а что тут не нравится? как бы ты сделал?

а что тут не нравится? как бы ты сделал?

я бы не юзал разный хтмл для серверной и клиенсткой части

разный хтмл? почему разный? т.е. где?

разный хтмл? почему разный? т.е. где?

ща я решу с вебпаком и может объясню

пиздец рот ебал вебпака

чо случилось?)

как вебпак инклуд проверяет?

относительно чего?

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

ты можешь через __dirname не париться

или прокидывать путь в конфиг

вот только он не работает если ${__dirname}/../src

а есть regexp указывать то как он смотрит?

относительно context?

или относительно папки где запускается?

есть path: path.resolve, path.join, etc, чтобы быстро ориентироваться во всякой неведомой фигне для mac os x есть Dash и доксеты для этой неведомой фигни, для других ос тоже есть аналогичные штуки, для cli есть cheat и еще пара подобных штук

ERROR: S client not available

короче спасибо пацаны я разобрался

и надо юзать path.resolve вместо __dirname

MoscowJS 32 в офисе Яндекса 28 июля (будет трансляция): TypeScript-пакеты, тестирование, CI, интернет вещей и JavaScript — http://vk.cc/5o7CWA хоть в яндексе места довольно много, но лучше не тормозить и регистрироваться сразу и заранее, а то потом можно обломаться)

MoscowJS 32 в офисе Яндекса 28 июля (будет трансляция): TypeScript-пакеты, тестирование, CI, интернет вещей и JavaScript — http://vk.cc/5o7CWA хоть в яндексе места довольно много, но лучше не тормозить и регистрироваться сразу и заранее, а то потом можно обломаться)

А будут работать кондиционеры? или будет как на node.js?

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

реквестируем в чатик организатора 32-ого MoscowJS

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

Да, да, по этому не досидел до конца.

https://twitter.com/chicoxyzzy/status/753989377722880001

Наканецта

Сильно поможет если легаси браузеры ещё лет 5 останутся?

это v8. а значит в ноде они уже завтра будут)

Сильно поможет если легаси браузеры ещё лет 5 останутся?

async/await в промисы преобразовать можно

https://hyperterm.org/

терминал на реакте!

Вопрос, а зачем?

за тем же, зачем и atom

возможность гораздо проще внедряться и кастомизировать

https://github.com/zeit/hyperterm/issues/37#issuecomment-230342086

https://github.com/peterramsing/lost

бля пацаны это пушка

за тем же, зачем и atom

Закупаем плашки памяти, react-vt100 edition

мой мозг отказывается понимать это: webpack confg module.exports = { entry: [ './index.js' ], output: { path: '/tmp/v2', filename: 'index.js' } }; .babelrc { "presets": [ "es2015-webpack" ] } index.js import { noop } from 'lodash'; noop(); analyzer lodash: 503.54 KB (99.8%) <self>: 1.09 KB (0.217%) что я делаю не так?

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

возможность гораздо проще внедряться и кастомизировать

https://github.com/zpao/hypertheme

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

ага, и конечно же это атомовское чудо сюда тоже завезли https://github.com/zeit/hyperpower

Есть ещё black-screen

https://github.com/shockone/black-screen

Emulator for the 21st century - в 21 веке давайте делать проги так, чтобы у пользователей все равно не хватало оперативки и все тормозило. А то навтыкают по 8гигов оперативки и корайпять обмажутся и думают что все летать будет

Для меня загадка - мощность пц растет, а венда все равно тормозит

Как так

Есть ещё black-screen

им я пользовался он какой-то не такой

Да