I'm not talking about how webpack turns it into a rendering function. That's obvious.
I mean conceptually, props come in (like arguments) and events go out (like the return statements). A component is a fancy kind of function that can keep emitting results and accept changing inputs over time. In truth it more closely resembles an Observable, but an observable is ALSO a slightly fancier kind of function.
If you just think of a component as thing that takes input props and emits output events you're well on your way to using them well.
The worst components are ones that might as well just be a big single page script. That's zero percent better than the spaghetti we're working so hard to replace. That's just repackaging all the problems of the old imperative class-based legacy code.
New vue programmers are ok at handing props to components, but they rarely use events effectively (at first). As a result they end up using a lot of global state, a million little data props and relying on imperfect globalized tools like Vuex or other imported dependencies for every little variable.
Vuex definitely has its uses, but not as many as you might expect given the way it is overly-emphasized in common tutorials. It's easy to walk away from an "Intro to Vue" video with the idea that all data must live in Vuex all the time. That's a really undesirable situation.
Although vuex is a well-organized (many would say over-organized) state machine, it is important to remember that it is still a kind of global injection and deserves to be considered as such.
Data persistence should be something that happens near the top of your component tree, not down in the guts.
Your first thought with a component should be: "How can I offload the handling of the results of this component to my caller?" The answer is usually going to be events. A component that simply accepts props and emits events can be re-used in more contexts than one that relies on an external global state to operate.
They're just fancy shorthands for a prop / event handler combination. They are fundamentally no different from props and events, but the syntax is important to understand.
Most of good component design boils down to answering the following question: What do I want to put in data, computed, and props?
Data is the place where temp data goes that is not sensible to persist in Vuex or other application-wide global state, usually because its use is very specific to the operation of this particular component. There really should only be a few variables in data.
Most components only need one or two variables in data. If you have a large amount of data variables, it's worth taking a little time to stop and build a mini-dependency tree for yourself. You will probably find that almost everything can be written in terms of computed transformations on a small number of data and properties.
Defining your values using computes will lead to a lot less "oh I forgot to update that variable"-style bugs.
If you have more than a few data variables you probably (a) aren't leveraging computeds and properties, or (b) are trying to implement too many features for just one component. It is important separate your concerns in components just like you do in any other kind of programming.