>При двусторонней данные будут менять при вводе в поле ввода.
Это будет тоже изменением данных через код, т.е. и при изменении из кода меняется интерфейс, и при изменении из формы вызывается этот же код и меняется интерфейс, и этот алгоритм один и для односторонней связи, и для двухсторонней, потому что и там и там это работает через функцию обратного вызова (иначе технически нельзя).
Пример про отсутствие биндинга верный, но это не живой пример потому что все формы обрабатываются (в 99% процентов случаев кодом).
Внутри функции обратного вызова в любом случае прописана логика работы с данными. Если меняется структура интерфейса в результате изменения данных, или структура самих данных (я так понял что это значит), то в одностороннем биндинге делается тоже самое (получаем данные, обрабатываем, выводим новые в нужном обработанном виде).
Пример хороший, но технически не получается его наложить. Технически педаль сама не может отпуститься, потому что браузер не умеет писать данные форм в модели без нашего участия. В этом и вопрос, как-раз. Если это тоже делаем мы, точно так же, как и в односторонней привязке, тогда что такое двухсторонняя привязка?
Чистый это значит всегда одинаковый результат при одинаковых данных на входе. Конечно, компонент не может быть чистым в прямом смысле, ведь есть дочерние компоненты, но как определение, оно применимо к компоненту.
Вариантов тонна, вопрос какой лучше. Сделать кашу, делать как хочется мы всегда успеем, но мы как специалисты должны двигаться в сторону идеального (так не бывает, конечно), и всегда искать лучший вариант.
От этого и строится вопрос, как безболезненно делать композицию из компонентов.
Комментарий супер, но вопрос всё еще открыт, потому не отмечу решением, потому что интересен именно опыт людей, конкретные решения, чтобы произошел обмен опытом и можно было пересмотреть свое решение более взвешенно.
Я написал выше. Вы не можете переиспользовать его, значит компонент жесткий. Это как прибить доску гвоздями к табуретке, а потом думать как её снять и прикрутить к стене. В таком случае вы делаете доску, которая содержит технические отверстия, и если они подходят и к стене, и к табуретке, вы можете спокойно прикрутить доску куда-угодно.
>они от этого не перестают быть презентативными
Вы правы, не перестают, если презентативность это просто вывод информации на экран, но в этот термин закладывается другая идея, прочитайте информацию выше.
Но становится помесью. Если вам потребуется три инстанса с тремя разными данными, вы уже не сможете этого сделать, потому что данные зашиты в компонент. Значит он уже не полностью презентативный. Поэтому потерялась гибкость переиспользования компонента. Я понимаю что в этом и идея разделения этих типов компонентов.
Если они не чистые, значит частично или полностью самостоятельно получают данные из вне, т.е. становятся помесью контейнера и простого элемента представляющего разметку под данные, что не полностью решает проблему разделения сущностей и переиспользования компонентов, потому что смешивая эти сущности, гибкость переиспользования компонентов понижается.
Поэтому четко разделяя сущности достигается максимальный эффект, а для этого нужно чтобы
презентативный компонент был чистый, а контейнеры только передавали данные и делали композицию из презентативных компонентов.
Мне не нравится что нужно сначала составлять общий список ключей через defineMessages, а потом нужно еще отдельно держать локализации, в которых должны быть переводы по ключам из defineMessages, причем ключи могут быть разные.
Поэтому фактически вместо создания пары ключ + перевод, делается одна пара ключ + описание ключа в defineMessages, и вторая пара ключ + перевод. Фактически, defineMessages делает прокси-объект (грубо), и он нам не нужен, но избавиться от него, видимо, никак.
>кто из них должен владеть состоянием?
Никто, они все зависят от данных в сторе, одни напрямую, другие через свойства компонента.
>но что будет, если он не создается пока массив пустой?
Будет сообщение что список пуст, а в лучшем варианте, будет виден лоадер на период загрузки данных (если они должны загрузиться)
>а отдельный элемент наверняка будет с возможностью редактирования, а это уже локальное состояние, которое придется как то согласовывать с родительским компонентом список
Здесь есть одно огромное НО, в виде завязки на данные стора, т.е. переиспользовать компоненты будет нельзя, если завязывать редактор напрямую на данные из стора. Если есть редактор текущего пользователя, например, то нельзя ему скормить другую модель и получить на выходе обновленную модель после редактирования. Это делает решение максимально жестким. Поэтому и делаются выбросы данных в родительский компонент через функции обратного вызова. Это создает связь между компонентами, но остается огромное пространство для маневров по вариантам использования компонентов, поэтому это не проблема.
>но это еще пол беды, вся беда начнется с счетчиками, которые не связаны со списком отношением родитель-потомок, счетчикам придется постоянно получать состояние от компонента, которого вообще по хорошему не надо знать.
Со счетчиками вообще не понял, если честно. Просто берем список из стора и делаем фильтр, и выводим число. Источник правды останется один, это стор. Никакой зависимости от компонентов.
>а теперь пришел менеджер/заказчик/продакт и говорит такой, а вот тут еще хочу кнопки "отметить все выполненным/невыполненным", и мы идем пилим новый компонент, и организуем еще два слоя связанности - со списком и со счетчиками, ради того чтоб согласовывать общее состояние
Тогда делаем компонент, который меняет данные в сторе, и остальные компоненты сами обновят свой интерфейс. Зависимости от компонентов тоже нет, только от стора.
Может быть я не понял сообщения, но вообще не вижу проблем при реализации. Данные в сторе общие, связи только на уровне функций обратного вызова (что обеспечивает переиспользуемость компонента и это хорошо, это базовая практика для любых компонентов, см. API компонентов любого UI kit'а). В вашем примере ни счетчик, ни форма создания Todo, ни список друг о друге ничего не должны знать, все только на стор завязыватся. Локальное состояние будет только у редактора конкретного Todo. Можно еще переделать форму создания Todo, чтобы она не на стор завязывалась, а наружу данные выбрасывала через функцию обратного вызова.
cocomuffin, в таком случае страница, допустим, будет перезагружена посреди загрузки, и получим что данных в стопе нет, спиннер будет виден, а запрос вовсе не отправлен, и спиннер будет крутиться бесконечно.
Получается надо отслеживать такие кейсы, а это лишняя головная боль. Опираясь только на данные без состояний, пользователь бы увидел что данных нет и началась бы новая загрузка данных.
Кода меньше, сложности меньше, сценариев для обработки меньше, значений в сторе меньше.
Да, и поэтому у меня и вызывают вопросы многочисленные доки, где хранят намного больше данных, временных.
Может быть есть кто так делает (хранит локальные значения в сторе), и может обяснить для примера, зачем они это делают.
Тогда, может быть вы можете обьяснить, какой мотив делать так (?): https://redux.js.org/advanced/async-actions
Они в стор передают isFetching, didInvalidate, которые по сути временные значения на период загрузки данных или ввода пользователя.
Не понимаю мотивацию хранения этого в сторе. Если они перезагрузят страницу, всё это накроется, потому что запросы нужно заново отправлять, и стор будет со сломанными данными.
Они пишут:
>For every list of items, you'll want to store isFetching to show a spinner, didInvalidate so you can later toggle it when the data is stale, lastUpdated so you know when it was fetched the last time, and the items themselves. In a real app, you'll also want to store pagination state like fetchedPageCount and nextPageUrl."
Я смотрю на Redux, на локальное состояние компонента, и по идее от локального состояния можно отказаться в пользу Redux. Получится больше контроля, отказ от хуков React, четкий поток действий, доп. инструменты для отладки, т.е. будет удобно, и в перспективе еще и управление состоянием можно в памяти хранить, вплоть до мелочей (если понадобится).
Единственное, нужно будет стор вычищать, но это не большая проблема.
Допустим у нас 100 роутов в приложении и 200 компонентов. Если все экшены и редьюсеры держать в одном месте (папки actions, reducers), получится здоровенный список.
Так как при работе приложения большая часть редьюсеров и экшенов будет не подгружена (они будут загружаться по требованию), то смысла держать все эти файлы вместе нет:
а. Не будет понятно где какой редьюсер, или экшен. Их будет очень много, и не поймешь какой от какого роута или компонента.
б. Принято держать сущности в файловой структуре по какому-то принципу, и если в нашем случае принцип это формирование групп файлов связанных с одним компонентом, то эти файлы редьюсеров и экшенов нужно выносить именно к компонентам, если только они не глобальные.
Вот и получается, что папки редьюсеров и экшенов можно вовсе удалить, и держать все эти файлы рядом с компонентом, с которым они загружаются и выгружаются.
abberati, присоединяюсь к Abr_ya, спасибо за ссылку :+1:
Действительно, отказавшись от инструмента всё-равно в результате получится велосипед. Нет смысла не использовать сразу готовое решение, не говоря про его клевые особенности, которые помогают в разработке.
