more
and more
move rebase commit refreshing into existing abstraction
and more
and more
WIP
and more
handling clicks
properly fix merge conflicts
update cheatsheet
lots more preparation to start moving things into controllers
WIP
better typing
expand on remotes controller
moving more code into controllers
The way the `if` expression in `deactivateContext` was composed,
it was possible to have it to evaluate to `true` even though the
`view` variable was `nil`.
As far as I can tell, this seems to be only possible during tests.
Nonetheless, I think the expression looks more "correct" this way.
Hard to choose between the lock with a defer unlock in an anonymous function
vs just having an explicit unlock at the end with additional unlocks before
any early returns. The former is less error prone, but the former is much more
readable, especially if the anonymous function would have needed to return
an error value.
There has got to be a better way around this but if we're returning a Context
from a function (Context is an interface, not a concrete type), even if we
return nil, on the calling end it won't be equal to nil because an interface
value is a tuple of the type and the value meaning it's never itself nil,
unless both values in the tuple are nil.
So we're explicitly returning whether or not the underlying concrete type is nil.
