For additional context, I'm being asked to name my assets and organize elements into components. I'm not quite sure what that means. Would components be considered groups (ex. text, call to action, gradients, etc.) or is this something else entirely?
In simple terms, a component is any part of your application that can be logically grouped and thought of as singular element, that ideally can be reused as a building block for the rest of the application. This component may have other components within it, or may be used within other components, but each individual "component" is a standalone thing.
So for instance you may have a website with a header on every page. So you may create a "header component", then you can just reuse that header component for every page instead of writing the code from scratch. This header component may contain a "search bar component" and a "navigation bar" component that are their own standalone elements, they are used in the header but they could just as well be reused elsewhere on the site.
It's up to you where to draw the line on what is a component and what isn't, some people may create a simple "button component" if there needs to be enough customization of default buttons to warrant it or you may just leave buttons as regular buttons and not consider them components.
I find this guide on Atomic Design a good starting point for breaking out your elements into logically grouped components, https://bradfrost.com/blog/post/atomic-web-design/.
(Likely your components will fall into the molecules or orgranisms in that guide, but again if you find it necessary any of those steps could be made into reusable components.)
So according to Material Design:
Their definition of Components is as follows:
Material Components are interactive building blocks for creating a user interface.
i.e. Buttons, App Bars:Top, App Bars:Bottom, Cards, Lists, Text Fields, etc.
I think a simple answer to how you should organize your elements into components would be to follow how Material Design tackles "Components".
I'm using the AirBNB App as an example. Here are 2 types of cards they used in their UI:
So in this regard, I would put these elements together as Card Components.
To summarize, a commonly used practice in grouping and organizing elements as "Components" is primarily based on their nature and functionality. Buttons are tappable elements that does an action, Cards are a container of content and actions for a single subject, Text Field Inputs are areas where you can input data to be passed, etc.
You can probably look at the component tag and see that there is no guidance on its usage here on UXSE (at time of writing - so I will address it using the proposed answer here). So I am going to say that the answer is no, or at least there is no popular consensus on this to my knowledge.
For the long and more complex answer, theoretically, the definition of a component would probably depend on your particular design philosophy as well as how that design is executed. But that's not really a simple or practical definition.
Broadly speaking, I have seen components defined in a number of different ways based on the various design systems going around. So in general, you can define what a component is based on the:
If you define a component based on atomicity (e.g. Brad Frost's Atomic Design), then a component should be comprised of the smallest functional chunk of code/UI element. And you can either define a component to be that 'atom' or perhaps 'molecule' level (i.e aggregation of atoms) to cater for simple or more complex components.
If you define a component based on reusability, then it is probably the smallest interoperable unit of UI element that you create, which could be like a calendar/date picker or dashboard widget. But just be mindful that the level of reusability can also vary depending on the teams or projects that you share this within.
If you define a component based on modularity, then it is a somewhat loose definition between the two that we have previously defined. It can provide you with a flexibility to extend on it if required, but also has the characteristics of reuse (or replacement). However, it suffers from the fact that you probably have to create more strict definitions to remove some of the ambiguity for different teams contributing to the component library.