To a certain extent, I agree that you also don't want overly small components, but it feels a lot like the debate about function size. Sure, you don't want to wrap every statement in its own function, you want functions that are big enough to actually do something useful, but as a rule of thumb, smaller is better than larger.
This isn't a theoretical concern either. Like I said, I've had this issue with Vue before, and component sizes just bloated to the point where many pages were just single, chaotically interwoven components with dozens of state variables that theoretically were never used by each other, but in practice tended to be shared accidentally or out of short term convenience. At which point all bets are off and every bug becomes an exercise in figuring out what's going on.
That's not to say that that's a Vue-specific problem, because I've also had that issue in other frameworks, including React. But far less often in React, because it's much easier to deal with the pain when it starts with a simple refactor, than dealing with it a year and several new features down the line when everything is tangled together like a headphone cord in your pocket.
This isn't a theoretical concern either. Like I said, I've had this issue with Vue before, and component sizes just bloated to the point where many pages were just single, chaotically interwoven components with dozens of state variables that theoretically were never used by each other, but in practice tended to be shared accidentally or out of short term convenience. At which point all bets are off and every bug becomes an exercise in figuring out what's going on.
That's not to say that that's a Vue-specific problem, because I've also had that issue in other frameworks, including React. But far less often in React, because it's much easier to deal with the pain when it starts with a simple refactor, than dealing with it a year and several new features down the line when everything is tangled together like a headphone cord in your pocket.