feat: add UserModel::getReturnType() and RegisterController::getUserEntity() uses it

[christianberkman]

Description
See #1170
Refactor RegisterController::getUserEntity to use UserModel::returnType instead of the hard coded new User(). This allows for easy use of a custom User Entity without needing to extend the RegisterController and add the routes.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[kenjis]

Suggested change

	public function getUserEntity(): User
	/**
	* Returns User Entity Type
	*
	* @return class-string<User>
	*/
	public function getReturnType(): string

[kenjis]

Is it better to add createNewUser(array $data): User or something instead of getReturnType(): string?

[christianberkman]

That would omit the UserEntity entirely so we would still not be able to use UserEntity during the RegistrationAction?

[kenjis]

If we add the following method to UserModel:

    /**
     * Returns a new User Entity.
     *
     * @param array<string, mixed> $data The data passed to the constructor
     */
    public function createNewUser(array $data = []): User
    {
        return new $this->returnType($data);
    }

RegisterController would be like this:

    protected function getUserEntity(): User
    {
        $userProvider = $this->getUserProvider();

        return $userProvider->createNewUser();
    }

[kenjis]

@christianberkman
I think adding a method to create a new user is better than a method that just returns the user type string.
Would you like to make such an update?

[christianberkman]

Sorry typo. I meant

So do you propose the following? (My last code snippet)

I also read your snippet with createNewUser wrong and actually we are on the same line indeed.

Is it now better to open a fresh pull request since this differs from the original suggestion?

[kenjis]

Yes, it would be better to open a fresh PR.

And I propose to add the first parameter:

    /**
     * Returns a new User Entity.
     *
     * @param array<string, mixed> $data (Optional) user data
     */
    public function createNewUser(array $data = []): User
    {
        return new $this->returnType($data);
    }

Then, a dev can create a complete new User entity.
If a dev want to use Complete Constructor to the custom User entity, s/he needs complete data to construct a new entity.
Also, the CI4 Entity permits an empty instance creation, so we can just call it without arguments.

[datamweb]

I personally don't like using mixed, and I prefer to explicitly define the possible types as much as we can. For any other unexpected values, we can wait for bug reports from users.

[kenjis]

If we don't use mixed, something like this:
array<string, array|bool|int|float|null|object|string>

But it contains array, and it is not acceptable. Therefore,
array<string, array<array-key, array|bool|int|float|null|object|string>|bool|int|float|null|object|string>

But still contains array... Give up and use mixed.
array<string, array<array-key, mixed>|bool|int|float|null|object|string>

Which is better?

• @param array<string, mixed> $data (Optional) user data
• @param array<string, array<array-key, mixed>|bool|int|float|null|object|string> $data (Optional) user data

or something else?

[datamweb]

My choice is the second option because it strikes a balance between overly vague type definitions and overwhelming complexity. While it's not ideal, it offers a reasonable level of flexibility and clarity.

@param array<string, array<array-key, mixed>|bool|int|float|null|object|string> $data (Optional) user data

[kenjis]

I sent #1196
Check, please.