братан лучше беги

просто сразу

Ладно, забираю свои слова обратно:D

да я тоже офигел

ну бывает

хооотя в принципе это не дожно ничего сломать

но все равно это говнокод

хорошо давай так this.setState(prevState => ({searchFieldValues:{ ...prevState.searchFieldValues, [name]:value }}))

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

Привет, у меня ночной затуп, может кто поможет. Я передаю в компонент props {tableData.map(tableRowData => { const { id, ...formatData } = tableRowData; return ( <TableRow key={`${id}`} id={id} onEdit={onEdit} onDelete={onDelete} data={formatData} /> ); })}При первом render компонента - компонент не видит props. из-за чего происходит ошибка. render() { const { handleDeleteRow, handleEditRow } = this; const { data } = this.props; return ( <TableRowView data={data} onEdit={handleEditRow} onDelete={handleDeleteRow} /> ); }По идеи же props должны были передаться в constructor (конструктор у компонента такой) constructor(props) { super(props); autobind(this); }

Да, работает, спасибо, круто

const { handleDeleteRow, handleEditRow } = this; ?

но все равно это говнокод

где?

Я просто новичок в реакте, можете помочь собрать мысли в кучу, как это надо было сделать нормально? Хранить этот стетй в редюсере?

где?

в конструкторе

У меня глубокий стейт и сетстейт вот так писать приходится prev => prev.map((pr, i) => i === idx ? { ...pr, projectName: eventValue, errors: { ...pr.errors, projectName: false, }}: pr), это норм практика?

код пожалуйста на gist

У меня глубокий стейт и сетстейт вот так писать приходится prev => prev.map((pr, i) => i === idx ? { ...pr, projectName: eventValue, errors: { ...pr.errors, projectName: false, }}: pr), это норм практика?

норм

а юзать immutablejs для setState норм?

а юзать immutablejs для setState норм?

а ты так много данных хранишь в локальном стейте ?

форма ввода на 3 страницы

вообще сразу нет

и не важно сколько данных

я чет тупанул

вай?

toJS для каждого рендера делать оч дорого

а простые линзы?

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

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

https://gist.github.com/Matroskins/087f0715d711daa784b09380317daf3a вот код, не выкупаю почему render TableRow происходит с пустыми props

а где ты берешь this.props.data ?

из ContactTable

там оно точно есть

причем ошибка в первом render только, во втором props уже появляются.

ну так мб ты их где-то через асинк запрос получаешь ?

https://gist.github.com/Matroskins/886e1fc18befd3eda0107f99e493080e вот так получаю, они в localstorage храняться

render() -> componentDidMount()

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

проверяй что в стейте

вроде долно работать

спасибо, может на свежую голову что-то пойму)

я выкупил в чем было дело, там ошибка имен была, лол((

У меня глубокий стейт и сетстейт вот так писать приходится prev => prev.map((pr, i) => i === idx ? { ...pr, projectName: eventValue, errors: { ...pr.errors, projectName: false, }}: pr), это норм практика?

норм, если вдруг задолбает попробуй mobx)

У меня глубокий стейт и сетстейт вот так писать приходится prev => prev.map((pr, i) => i === idx ? { ...pr, projectName: eventValue, errors: { ...pr.errors, projectName: false, }}: pr), это норм практика?

может поможет https://reactjs.org/docs/update.html

со стейтом какой-то кошмар творится

именно. Не могу придумать никаких решений.

toJS для каждого рендера делать оч дорого

Там вообще не нужно toJs делать, это антипаттерн

Привет Если defaultProps в static, можно получать к ним доступ как Component.defaultPros.propName?

Можно но зачем?

Зачем - другой вопрос, сейчас просто интересно стало

Тоже самое с stateless, как я понимаю

Тоже самое с stateless, как я понимаю

С наличием дефолтных значений при деструктуризации это не актуально

Можно но зачем?

На вскидку пока придумал такое - показывать дефолтное значение компонента и его измененное значение, пока не знаю, куда это впихнуть, но главное можно ?

я думаю это слишком

? ну-ну

Можно но зачем?

1) шарить пропсы 2) сторибук или что-то такое это использует для вывода

1) шарить пропсы 2) сторибук или что-то такое это использует для вывода

А из статика то зачем доставать?

Что бы лишний экспорт импорт не делать ?‍♂️

Эм а как ты достучишься до другого компонента без импорта/экспорта?

лишний < —

То есть ты предлагаешь вместо экспорта объекта импортировать компонент и забрать объект у него, тем самым имплементируя наследование?

Хоть и частично

Тем самым уменьшая количество кода и отображая явные зависимости

а если надо будет удалить компонент-источник объекта?

А если метеорит упадет?

Удаление компонента это не такое редкое явление

Я не говорю что всегда так делаю (я так вообще не делаю). Я лишь ответил на вопрос что можно с этим делать

Технически можно но ни в коем случае не позволительно

ERROR: S client not available

Есть кто знает методы CKEditor5 balloon?

именно. Не могу придумать никаких решений.

у тебя все выглядит как простой todo-list. а зачем тебе оставлять поля с подвижным стейтом? они будут потом редактироваться? пересмотри пример todo листа на заглавной странице https://reactjs.org/ почитай по стейту еще раз, что именно должно контролироваться, другой пример из документации https://reactjs.org/docs/thinking-in-react.html#step-3-identify-the-minimal-but-complete-representation-of-ui-state иногда даже без стейта можно обойтись http://reactkungfu.com/2015/09/common-react-dot-js-mistakes-unneeded-state/ а так выглядит как будто тебе нужно постоянно рендерить новые стейтфул компоненты. реши где стейт будешь хранить.

у тебя все выглядит как простой todo-list. а зачем тебе оставлять поля с подвижным стейтом? они будут потом редактироваться? пересмотри пример todo листа на заглавной странице https://reactjs.org/ почитай по стейту еще раз, что именно должно контролироваться, другой пример из документации https://reactjs.org/docs/thinking-in-react.html#step-3-identify-the-minimal-but-complete-representation-of-ui-state иногда даже без стейта можно обойтись http://reactkungfu.com/2015/09/common-react-dot-js-mistakes-unneeded-state/ а так выглядит как будто тебе нужно постоянно рендерить новые стейтфул компоненты. реши где стейт будешь хранить.

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

именно. Не могу придумать никаких решений.

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

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

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

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

нет, это не чат. Это форма с опциональным количеством парных полей Ключ->Значение

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

нет, это не чат. Это форма с опциональным количеством парных полей Ключ->Значение

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

нет, это не чат. Это форма с опциональным количеством парных полей Ключ->Значение

если она не фиксируется тебе нужон стейт для каждого небольшого компонента где два поля ввода и каждый контролирует свой стейт отдельно

нет, это не чат. Это форма с опциональным количеством парных полей Ключ->Значение

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

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

Реакт просит поля ввода форм делать двухсторонним байндингом со стейтом, чтобы они отображали состояние стейта. Я делаю, и мне всё нравится. Но вот то, что я не знаю, сколько именно их будет, всё портит.

если она не фиксируется тебе нужон стейт для каждого небольшого компонента где два поля ввода и каждый контролирует свой стейт отдельно

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

Реакт просит поля ввода форм делать двухсторонним байндингом со стейтом, чтобы они отображали состояние стейта. Я делаю, и мне всё нравится. Но вот то, что я не знаю, сколько именно их будет, всё портит.

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

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

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

вот пример я делал для свлих целей, смотри на там на консоль пока водишь по цифрам. пример был поинтерактивней, просто я его уже перекорячил для других целей https://codesandbox.io/s/l71px5kpql

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

твои элементы должны сами себя добавлять в какой-то массив

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

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

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

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

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

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

вот пример я делал для свлих целей, смотри на там на консоль пока водишь по цифрам. пример был поинтерактивней, просто я его уже перекорячил для других целей https://codesandbox.io/s/l71px5kpql

эммм, не понял, как это применимо тут(

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

они могут добавляться в массив сами я думаю

эммм, не понял, как это применимо тут(

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

они могут добавляться в массив сами я думаю

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

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

ну я даже не понимаю какого размера форма у тебя будет

ну я даже не понимаю какого размера форма у тебя будет

Вот эти два поля. А их сколько угодно может быть.

Вот эти два поля. А их сколько угодно может быть.

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

может поможет https://reactjs.org/docs/update.html

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

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

Да, они так и делают) Но изменения массива вызывает перерендеривание )

Да, они так и делают) Но изменения массива вызывает перерендеривание )

ну чтобы они просто писали в массив форма > родитель > два поля ввода данные хранятся в массиве например

ну чтобы они просто писали в массив форма > родитель > два поля ввода данные хранятся в массиве например

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

Да, они так и делают) Но изменения массива вызывает перерендеривание )

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

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

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