Let's talk about data clumps. Data clumps are a code smell, and we remember that a code smell is an indicator that something may be poor about the architecture of your code. It's not necessarily that it's definitely is poor, it's just an indicator that it might be so.

What are the data clumps? Data clumps are when more than one piece of data is oftentimes found together. Martin Fowler gives a great example. Imagine for example that you have a start date and you have an end date, and you find these two pieces in your application oftentimes together. In other words, it's not that you are only finding the start date or only finding the end date but usually, you come in contact with both of them at the same time.
export class DateFilterComponent {
    @Input() startDate: string;
    @Input() endDate: string;
}
You have a start date and you have an end date, and that would imply that you can extract an object that contains both of these two things. So instead of passing around the start date and the end date separately, you pass around a date range.
interface IPeriod {
    startDate: string;
    endDate: string;
}
export class DateFilterComponent {
    @Input() period: IPeriod;
}
A good way to identify a data clump is that when one of the pieces does not make sense in isolation but only makes sense together. That's when you know that you have a data clump. So again, let's think about the date range example. Having a starting date makes no sense unless you have an ending date as well. But of course, again code smells are not necessarily always problems. So, of course, you could have a start date without an ending date hypothetically. It could be that the ending date is infinite for example. But this is purely hypothetical.

But this was a very obvious scenario. Let's talk about the scenario that is less obvious. What if you, for example, find a user params and a credit card params at the same location spontaneously. This doesn't feel like a data clump even if they are passed around together. It might feel like they're totally different things and thus shouldn't be coerced into one object. But it entirely depends on your application. If you're in a checkout process, and this is the previously defined credit card and previously defined user, then perhaps it does make sense to pass them around together. If you think about the term payer for example, then suddenly it makes a lot more sense. It's not a user, it's not a credit card, it's not a user and a credit card. It's a payer for the particular card and that kind of makes a lot more sense. Give it a serious thinker and try to describe the clump using one word. If you can find a word that does describe the clump pretty well then you're probably looking at something that wants to be extracted into an object and not kept as separate pieces. Let's just mention what the benefits of this would be.

So the first benefit is semantics. It's easier for a reader of your code to understand what they are dealing with if they have one variable because they then understand that these two things are two pieces of one thing. It is much easier for the reader of your code to understand what's going on if he has a single descriptive name for passed params.

The second benefit is that coupling fewer arguments to a method is better than coupling many arguments. So you are coupling to fewer things if you have fewer arguments.