Проект CLI и OS X инструмент для отладки React и React Native приложений. Ссылка #Project #React #ReactNative

Не перестанешь спамить своим каналом — забаню

https://facebook.github.io/react/docs/reusable-components.html#prop-validation что PropTypes работае только в development mode, а как реакт понимает, когда production, а когда developement

https://facebook.github.io/react/docs/reusable-components.html#prop-validation что PropTypes работае только в development mode, а как реакт понимает, когда production, а когда developement

NODE_ENV

Кто-нибудь знает что сейчас обсуждается в отношении High Order Component? Давненько видел issue что не удобно с ними из-за кучи проблем с передачей refs, вызовом методов оригинального класса и тп. Может есть ссылка на обсуждение?

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

по скайпу

react + redux + webpack

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

смотря какой проект

twitch youtube twitter api

на тематику доты

хотя можно на любую другую игру сделать

@Kreizo уже учавствую в одном проекте, а так бы попробовал

а как тот канал с jobs’ами реактовыми называется?

добавьте описание все чатов в описания групп, админы /сс @DenisIzmaylov

а как тот канал с jobs’ами реактовыми называется?

https://telegram.me/javascript_jobs не столько реакт, сколько js

добавьте описание все чатов в описания групп, админы /сс @DenisIzmaylov

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

о, спасибо!

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

и правда( ну gist создать и ссылочку на него

и правда( ну gist создать и ссылочку на него

а лучше .md в репе

красивее будет

а стоп, .md в gist рендерится?

есессно)

один движок же)

а, туплю, просто не пользуюсь ими, у меня для этого bitbucket

ребят подскажите как можно зарендерить iframe по клику если список рендерится после componentDidMount

ребят подскажите как можно зарендерить iframe по клику если список рендерится после componentDidMount

Попробуй react-router использовать, все эти вещи будет проще делать

добавьте описание все чатов в описания групп, админы /сс @DenisIzmaylov

Ok)

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

Класть

Подскажите, нормально ли в state компонента класть метод для работы со свойствами, конкретно - получать элемент массива по slug. Вроде бы натыкался на решение подобных вопросов через введение доп. массива и сопоставление, но не могу найти, т.к. не могу сформулировать вопрос( Теперь по существу?)

Класть

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

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

я могу, но я полнейшее дно, без прибеднений

я могу, но я полнейшее дно, без прибеднений

какие скиллы основные ? или только вкатываешься в реакт ?

обсуждали вроде сегодня что-то про сохранение пропсов в стейт? Лучшего варианта нет, когда что-то похожее нужно? Думаю насчет возможности передавать в компонент позицию элемента, а дальше уже только менять стейт или стили напрямую

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

Вызывать его как props.onChange.call(this), например

Или хранить в стейте с bind(this)

Вызывать его как props.onChange.call(this), например

нет, фишка в том, что onChange в defaultProps вообще в пропсы не попадает, он переопределяет метод класса

Не может быть такого

В смысле, реально?

ага, щс еще раз перепроверю

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

В this.props должна быть копия defaultProps

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

import React from 'react'; import classNames from 'classnames'; class Input extends React.Component { static propTypes = { // ... onChange: React.PropTypes.func } static defaultProps = { name: '', type: 'text', className: '', value: '', onChange: (value) => { console.info(Current value is: ${value}.\nYou should overwrite onChange method.); } } constructor(props) { super(props); this.state = { value: this.props.value || '' }; } componentWillReceiveProps(nextProps) { this.setState({ value: nextProps.value }); } render() { console.info(this.props) // здесь есть onChange console.info(this.onChange) // undefined const { className, type, disabled, notEditable, invalid, required, ...rest } = this.props; delete rest.value; return ( <input value={this.state.value} {/* но сюда как-то попадает onChange и он срабатывает */} onChange={this.onChange} type={type} {...rest} /> ); } } export default Input;

Из-за...rest

бля

Удали это и будет ок

точно, спасибо

delete в рендере, кстати, тоже подозрительно выглядит

delete в рендере, кстати, тоже подозрительно выглядит

Все норм, это не сайд-эффект

Из-за...rest

ты случайно не сидел 3 года назад в руби-конфе? ник знакомый

да. Было дело)

хах

Если ты про скайп

да

))

А у тебя там какой был ник?)

сорьки за офтоп, чуваки (в личку отвечу)

ERROR: S client not available

Какое у кого мнение о концепции разделения компонентов и т.н. контейнеров: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

Какое у кого мнение о концепции разделения компонентов и т.н. контейнеров: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

Я считаю, что чем больше в проекте папок на верхнем уровне, тем лучше: api actions components containers constants reducers Это минимум для приличного проекта

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

Начинаю с контейнера всегда, если только не уверен заранее, что компонент будет реюзаться в разных контекстах ( ui элементы )

не могу не оставить это здесь: https://www.youtube.com/watch?v=Xt5qpbiqw2g

Еще у дани есть статья про нормализованные сторы, которая много мне крови потратила

Потому что сначала я сам повелся, а потом стал работать в проекте, в котором предшественники повелись

И это ад, не делайте так никогда:)

Что плохого в нормализации?

Я считаю, что чем больше в проекте папок на верхнем уровне, тем лучше: api actions components containers constants reducers Это минимум для приличного проекта

Это не минимум нифига, константы и экшены не нужны, лишние папки и файлы

Это не минимум нифига, константы и экшены не нужны, лишние папки и файлы

Это же сарказм был

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

Серега сегодня весь сарказм убил, не понял сразу

Самое удобное для меня это делить компоненты через роуты

Экшены, редьюсеры и тд - успел устать от разделенных пока по гайдам учил

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

Ну по сути роут = контейнер, у меня просто пока до роутов не дошло, вся логика на одном экране крутится

Да, в моем понимании контейнер стал роутом

у меня весь проект в одном файле

теперь не знаю как его порезать что бы он работал

теперь не знаю как его порезать что бы он работал

Ножичком

Что плохого в нормализации?

тоже интересно послушать

Ночной вброс https://github.com/goatslacker/react-ssr-benchmarks

тоже интересно послушать

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

ну и сама нормализация - не всегда тривиальный процесс.

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

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

Так нормализация происходит отдельных кусков а не всего стора разом

Я считаю, что чем больше в проекте папок на верхнем уровне, тем лучше: api actions components containers constants reducers Это минимум для приличного проекта

actions/constants/reducers - меня лично упарили эти три фолдера потому перешел на ducks а containers/components - имхо не нужно, лучше делить на routes / components и внутри компонентов на логические части

Парни, у нас появилась группа по Vue.js - это библиотека для построения интерактивных веб-интерфейсов, которая фокусируется на ViewModel слое паттерна MVVM. Многие наверняка слышали о ней. Всем, кому это интересно, добро пожаловать: https://telegram.me/vuejs_ru

#webpack #isomorphic а кто-нибудь женил isomorphic-style-loader и extract-text-plugin?