🚧 Initial Discord message components v2 implementation

[Log1x]

🚧 Work in progress.

Completely blind & untested. Should be able to try it later today.

Edit: everything appears to be functional.

[valzargaming]

The v2 contract was an excellent idea, and something I'd like to see in other parts of the library. It would certainly cut down on a lost of instances of checking against hardcoded types like this.

[SQKo]

Please also adjust the class implements Components\xx to have the namespace imported per my previous suggestion

[SQKo]

Implement validation of $url like in Embed::ensureValidUrl()

[valzargaming]

Do we know if it's the same spec? We could just copy-paste the function here and do the same thing.

[valzargaming]

I've confirmed it's exactly the same except for File, in which case only attachment is allowed.

[SQKo]

Suggested change

	throw new \InvalidArgumentException('Section can only contain TextDisplay components. Use setAccessory() for Thumbnail or Button.');
	throw new \InvalidArgumentException('Section can only contain TextDisplay components.');

You are not checking wether the $component is a Thumbnail or Button here so it's better not to explicitly say that.

[SQKo]

On a second though, the spec is telling us to not hardcode this, so we should not validate this yet

Suggested change

	throw new \InvalidArgumentException('Section can only contain TextDisplay components. Use setAccessory() for Thumbnail or Button.');
	trigger_error('Section may only contain TextDisplay components.', E_USER_NOTICE);

[valzargaming]

I’m not comfortable introducing a change like trigger_error in this PR as part of new functionality. We have always made it a point to ensure that new features align with the library’s existing design, and currently, the only places where trigger_error is used are in __construct methods related to the initial creation of the Discord class and its associated CacheInterface. Making this change here without a broader review of the library to assess its justification elsewhere would be premature. If we decide to introduce this pattern, it should be considered separately from this PR.

[SQKo]

Then don't throw the errors, remove the argument checking, and leave the type Component in the parameter while changing the phpdoc @param TextDisplay for now

[SQKo]

The spec is telling us to not hard code the supported components yet (anyway leave the phpdoc as is)

Suggested change

	public function setAccessory(Thumbnail|Button $component): self
	{
	$this->accessory = $component;
	public function setAccessory(Component $component): self
	{
	if (! ($component instanceof Thumbnail || $component instanceof Button)) {
	throw new \InvalidArgumentException('Accessory may only contain Thumbnail or Button component.');
	}
	$this->accessory = $component;

[valzargaming]

I agree with this, with the condition that throw new \InvalidArgumentException should be used instead for now.

[SQKo]

No, throwing error is the same as hardcoding it, the spec tells us NOT to

if you insist users should be informed then go back with my previous suggestions of trigger_error() as the E_USER_NOTICE doest not throw error but showing notice tracing to this code in their logs.

[valzargaming]

The rest of the library does not do this. It should be a separate PR.

[SQKo]

According to the spec, using the components v2 may disable content and embeds, it would be good to warn the users in the MessageBuilder to avoid confusion

Also seems this PR has not supported webhooks yet