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

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

а если почти все они нужны и используются? )

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

ну вот поддерживать с типизацией проще :)

о каком примерном количестве входящих параметров вы спорите-то хоть?))

с типизацией всегда проще. Я даже расставляю JSDoc в ванильном js коде, ибо тот же WebStorm прекрасно это понимает. Но это не подорожник от всех болезней )

вот теперь вспомни, с чего диалог начинался)

Да, JSDoc - это круто

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

и это так и есть и проверено многократно на опыте и на больших и даже малых проектах ) и не только на js

никто не запрещает это юзать, но до добра обычно не доводит ) Но есть нюансы, как и везде

🤦‍♂

Когда в конструктор передается 100500 полей, это признак высокой кастомизации

😄👍

Критикуешь - предлагай

И чем это плохо

высокая кастомизация и объекты-комбайны чем плохи?

тем, что в определеный момент, ты не сможешь контролировать все 100500 параметров

можно минимизировать риски, конечно