feat: add guest user

[skjnldsv]

Features:

• Creates a new getGuestUser method that looks similar to a normal user
• Add a way to monitor displayName change to so whatever you want (reload an avatar, or change other stuff...)

Code snippet example

// Watching for displayname change in vue component
data() {
	return {
		displayName: getGuestUser().displayName,
	}
},

mounted() {
	subscribe('user:info:changed', (guest) => { this.displayName = guest.displayName })
},

[susnux]

Still not fully sure about the event thing, would it make more sense as an event-bus event ?

I think the events make sense when you listen to a specific object / instance.
In this case it is both (as the guest user is unique) meaning its both:

• a global state
• an instance event

Maybe it makes things easier to work with (with current design of nextcloud-auth) when having a global event like auth:guest:display-name-changed (or any other wording 😅 ).
But I am fine with both, whatever you find easier to work with.

[skjnldsv]

Maybe it makes things easier to work with (with current design of nextcloud-auth) when having a global event like auth:guest:display-name-changed (or any other wording 😅 ).

user:properties:changed ?
So we can also use it for the NextcloudUser ?

That would differenciate for other like

• user:preferences:changed
• user:config:changed
• user:info:changed
  or something ?

[skjnldsv]

Done! With tests!
Using user:info:changed as I think it would make sense later to extend the Nextcloud user too and have more infos like email, pronouns... etc

[susnux]

Either

Suggested change

	export function getGuestUser(): GuestUser {
	export function getGuestUser(): NextcloudUser {

Or we would need to also export the type of GuestUser.

[susnux]

If we would export this class type (skip this depending on the other comment), then the type includes this private field.
Also it is accessible and only marked private for typescript.

You might consider instead using standard ES visibility:

Suggested change

	private _displayName: string | null
	#displayName: string | null

[skjnldsv]

I thought # was dropped in the end? 🤔

[susnux]

No they are standardized in es2019:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties

Its more like protected but enforced by runtime, meaning you cannot access the property from outside the class.

Whereas the typescript private, protected, and readonly are just types which get stripped away:

Meaning you could still access those private fields, while #something will throw an exception:

---

In the end its not really important, both have good reasons to use or not to use, it depends :)

[skjnldsv]

No, absolutely!
But I remember using the # a while back, when it was drafted and about to be accepted.
But I also remember that we rolled back and stopped using it 🤔

[susnux]

there are some places using it, but it really is not that important.
If you mess with private fields you better know what you are doing, so its your risk.

Meaning its just a matter of taste if you prefer Typescript sugar or Javascript syntax.
E.g. a benefit of Typescript sugar is that you can unit test it (while also there are some guidelines that discurage you from testing private properties, but thats another topic^^).

[susnux]

Looks good but we need the type adjusted or exported
https://github.com/nextcloud-libraries/nextcloud-auth/pull/795/files#r2077161323

[susnux]

Damn did not saw the auto merge 😮‍💨

[skjnldsv]

Damn did not saw the auto merge 😮‍💨

#799