Вопрос по архитектуре Это нормально если дочерний компонент вызывает родительские методы

с целью изменить состояние родителя
Мне кажется это ненормально.
Каждый компонент должен только свои методы вызывать и сам менять свое состояние

А для передачи данных снизу вверх, нужно делать "подслушиватель данных" между ними.

Я прав ??
Мне абсолютно не нравится стиль кода коллеги. У него дочерние компоненты вызывают родительские методы.
Имхо он нарушает принципы SOLID

Подскажите...

Нет вы не правы, прочитай про паттерн реакта lifting state up

"подслушиватель данных" Как вы себе это представляете?

делаю метод у родителя listenData у потомка делаю pushData внутри pushData(){ this.props.listenData(какие то данные) }

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

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

Совершенно верно подметили. Но я это делаю ТОЛЬКО для ПЕРЕДАЧИ ДАННЫХ ВВЕРХ. Но никак не для "оперирования" состоянием родителя

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

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

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

ясно, ок, спс

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

Впринципе я не собираюсь радикально что то менять. У меня тот же принцип. Передача функции родителя потомку как пропс. Разница лишь в том что мои функции a) называются importData и exportData b) они занимаются ТОЛЬКО ПЕРЕДАЧЕЙ ДАННЫХ, не вычислениями и тем подобным А него методы называются doSomethingOfParentLogic и естественно когда $childComponent->doSomethingOfParentLogic() у меня ощущение что child компонент как бы за родителя делает его дело

Ничем не отличается от способа вашего колеги

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

doSomethingOfParentLogic() Этот вариант лучше так как иначе мы скатимся в вуевский эммит событий

Вам надо смотреть каждый частный случай, например, кнопка не должна принимать функцию "printMessageOnScreenOnClick", кнопка просто должна принимать функцию onClick, а что при этом делать - конечно, решает родитель.

вот вот. А чем плох эмиты vue вот они более строго к этому подошли имхо. более понятнее что ли. но конечно кто как привык. Но у vue эмит имхо правильней кажется

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

Там подход другой, в реакте нету своих событий в принципе.

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

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

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

Ну, блин, дом так работает) Потому и во вью так сделали, думаю

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

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

У меня нет опыта на vue, знаком только концептуально, так что не имею права судить

Та что же, все, что не "как мне формочку отправить без перезагрузки страницы в реакте" - оффтоп?) Помилуйте) Пятница к тому же)

Универсальные решения бывают. Линукс например, так что факт про сильвер буллет слишком перегибают

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

Могли бы ссылки дать почитать. Что плохого в строгих композициях. Строгость только помогает коду больше читабельности.

Что такое "строгие композиции"?

Я еще раз приведу пример. Линукс - сильвер булет ОС. Задача фреймворка\либы для фронта намного скромнее, так что я лично за то что пока мы не достигли хотя бы первой ступени развития, где бы большая часть подкапотной работы была скрыта за абстракциями веб фреймворка.

Какая там строгость, я вас умоляю

https://www.youtube.com/watch?v=RgwursPHWm0

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

Эта строгость достигается с помощью СТМ

в чужой храм со своим уставом?)

да на самом деле устав-то один, просто чутка детали реализации отличаются.

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

++

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

Просто "свои вещи" в разных фреймворках для компонентов тоже слегка отличаются

Надеюсь сове там не икается😂

Как теперь это забыть😂

Если вы пришли из бекенда - вам уже концепция хранимого компонентом состояния должна глаза мозолить😁