Fix so logging in with GitHub without a nick works again.
I introduced this regression when I wisely forced Lobby's nick field to be an Option<Nick> rather than String. That means no more empty-string as a Nick, which is good, in practice, but introduces two other problems: non-Nick prefixes that could turn into Nicks with more characters and empty strings representing no GitHub username specified.
The solution is to have a separate login page that effectively has a nick-in-progress String that turns into a Nick when the nick is finalized and then to pass that Nick into Lobby as a property. Then, in the lobby, the nick field will simply be Nick and not Option<Nick>. I'm doing that work as issue (#1376) and wound up realizing that I had broken GitHub login as I began that refactor.
Fixed in login-1376, but won't be deployed until I've also added more restrictions to nicknames (#1367) and provided minimal feedback on what is disqualifying a nickname candidate (#1366).
Fix so logging in with GitHub without a nick works again.
I introduced this regression when I wisely forced
Lobby
'snick
field to be anOption<Nick>
rather thanString
. That means no more empty-string as aNick
, which is good, in practice, but introduces two other problems: non-Nick prefixes that could turn into Nicks with more characters and empty strings representing no GitHub username specified.The solution is to have a separate login page that effectively has a nick-in-progress
String
that turns into aNick
when the nick is finalized and then to pass thatNick
intoLobby
as a property. Then, in the lobby, thenick
field will simply beNick
and notOption<Nick>
. I'm doing that work as issue (#1376) and wound up realizing that I had broken GitHub login as I began that refactor.