latestchatty / webchatty

Integrated standalone chatty system with Node.js backend and Angular frontend
MIT License
5 stars 1 forks source link

Add AuthorType to posts #10

Open boarder2 opened 9 years ago

boarder2 commented 9 years ago

It would be nice to have the type of author returned by the API, that way the clients can do highlighting based on the type without having to do a bunch of string comparisons. I believe this is something that just about all clients currently do and it would be cool to have it in one place so the lists can be maintained in one place.

The only type we wouldn't be able to handle would be a self type since we don't know the name of the user accessing the information.

Suggested types:

Some of these will require a list of known names for the types. There is also the possibility that more than one type could apply - suggestions on how or if that should be handled are welcome.

Some of this could be implemented today, some will require more work behind the scenes and may not be possible until official integration starts but I thought I'd get this idea out there.

Alternatively, we could maintain lists of Staff, Mod, GameDeveloper, etc through the API that each client has to retrieve and then they can do the determinations internally but it seems like if we already have that info we might as well pass it along in the same place it gets used.

electroly commented 9 years ago

I've thought about something like this in the past. My roadblock has always been that I don't want to hardcode the list of groups or usernames, instead it should be configurable. But by whom? If the admin has to do it, the lists will never get updated. We have that problem with the moderation guidelines page; it's difficult to get changes through. It would be nice if some trusted users in the community could be granted the ability to set up these groups. I was thinking this could be a moderator privilege. We'd create an API and UI for setting up the groups and restrict it to moderator accounts.

It's my preference to just serve up a JSON file with the groups and usernames in it and let the clients handle it. They can cache it once and use that information forever. This is how I handle the lightning bolts; clients that care can ask for the information once and cache it, and clients that don't care can ignore the functionality.

boarder2 commented 9 years ago

Agree with the first part. Should definitely be self serviceable by someone other than an admin.

Not entirely sure if I like the idea of clients having to cache a bunch of lists of usernames for each of the groups. Though, it would solve the question of what to do if someone were part of multiple groups. That could also be done by a simple JSON array for the groups a user was part of.

If it's not provided as part of the post, the consumer would have to loop through all the groups and all the usernames to find if it applied to a post. That seems like a lot of extra overhead for consumers to put that in an indexed or quickly searchable list then have to iterate over it every time versus it being a quick lookup against the user/group table in a database.

electroly commented 9 years ago

The API already requires clients to be rather complex, I'm not super worried about this making it worse. I don't think a precomputed hashtable is a that big of a deal. You could get CSS to do it for you, like ChromeShack does, by using the author name (or maybe a hash of the author name) as a CSS class and then emitting styles appropriately for the users that are in groups.

My thoughts about including it with the post are: