есть n чистых функций, которые должны использоваться в одном единственном компоненте. Правильно ли хранить такие функции в одном единственном файле (utils.js например), который будет как хранилище функций для компонентов?
В моем понимании, если функция используется только в одном компоненте, то ее стоит хранить в самом компоненте. Но если таких функций, используемых в этом компоненте много, то лучше их вынести куда-то, чтоб не засорять код компонента.
почему они засоряют код компонента, если они и являются кодом компонента?
если нет необходимости в объявлении этих функций внутри тела функции компонента, а функций таких много, то мне кажется, что это засоряет файл компонента, или я ошибаюсь? это не является "засорением" ?
https://sova.dev/ru/why-utils-and-helpers-is-a-dump/
как тебе или команде удобно будет. главное, чтобы это читаемо было. можешь рядом с файлом компонента положить ещё один, два, пять, десять файлов с результатами декомпозиции.
да, тут речь идет о переиспользуемых функциях, а я говорю о функциях, которые не переиспользуются, а используются только в одном компоненте, но вопрос в том, где лучше хранить их при большом количестве этих функций.
ну я бы сначала крепко задумался про “почему их много” и “почему они все относятся только к этому компоненту”, а не “куда их положить"
ладно, спасибо)
Интересная статья, но мне кажется такой подход стоит применять, если над проектом работает команда от 4-х / 5-ти разработчиков, и соответственно проект довольно большой, в иных случая можно обойтись всё таки utils/helpers.
у нас 40 человек и есть utils
Мне пока не приходилось работать в большой команде, но вам как раз, мне кажется, стояло бы задуматься о том, что автор пишет в статье)
мне кажется, команда сама в состоянии решить, нужны ли им утилити функции отдельно или нет
а какая проблема это делать одному человеку? слишком сложно вынести общий код в отдельную директорию?
Не всегда есть бюджет, чтобы долго задумываться над каждым кусочком кода и часто проект нужно разрабатывать быстро, реалии)
славная байка, слышали )))
Это "быстро" очень быстро закончится)
обычно проект, над которым много дуамают, оказывается дешевле того, который делают быстро. это работает для вообще всех проектов. кроме ловли блох
Да я знаю, но не все это понимают)
Не, если у вас мвп, который при удачном раскладе все-равно выбросят и будут переписывать с нуля - да, в принципе, пофиг на архитектуру
удачный мвп к сожалению обычно не выбрасывают а просят вкидывать в него новые фичи:D
Это уже проблема коммуникации)
та понятно что не надо, но по моему опыту кейс: "напишите мвп, если берем раунд/получаем хороший фидбек/другие критерии то будете писать с нуля нормально" - очень редкий, обычно просят на базе этого мвп же продолжать, а говно которое наворотили за те 2 недели марафона "отложим в техдолг и будем потихоньку разгребать" 😄
да, все так и есть
настольгией повеяло
ой это очень часто происходит :D
с опытом это можно в условие ставить, что, мол, делаем всё как положено :)
если заранее смог договориться то вообще ништяк конечно)
Ну у меня так было говорили нужна производительность вот код а он по последним коммитам был написан 10 лет назад и улучшения производительности получилась лишь тогда когда переписал все на новый стиль и убрал уйму библиотек которые на данное время уже поддерживаются в js и проект ожил и кода стало на 10к строк меньше)
Обсуждают сегодня