I'm using TypeScript in an Express app. I want to write middleware that authenticates the user and sticks them in req.user... but only on routes that require being logged in. But the type of `Request` doesn't have `user` in it. What do I do? (See non-solutions in the next tweet.)
Conversation
This is what I do now. But you didn't actually show what this does to authentication. This is what I have in practice, in every single route:
const user = await findUser(req)
if (!user) {
res.redirect(paths.login())
return
}
> 50% of my route code is this.
1
4
I don't see any way around this, because there's no way for the `findUser` method to abort the request early. I mean, it can `res.status`, but it can't force the calling route to terminate.
3
2
That's why the solution is monads
1
5
I'm not sure whether this is a joke?
2
7
It’s definitely not advice! But maybe not a joke? Monads, or more generally delimited continuations, have the interesting property of being able to accumulate type information by virtue of each continuation being an overloaded function of the previous state to the next state.
2
3
But that’s true of any generic combinators you’d use to build up routes, whether or not it’s monadic. So yeah, it must be a joke :-p
1
As an aside, this is why I’m still a believer in “success typings”. You can’t model everything with types, so you shouldn’t be tempted to try. It’s kinda fun to watch you solve these puzzles though, because I suspect you will eventually rage quit contemporary type systems :)
2
4
I dunno, I had mixed feelings about using Dialyzer’s implementation of success typing. It was kind of annoying in practice to have it silently ignore ambiguously typed stuff. Not sire if that is more a problem with the tool ir success typing in general.
1
The success typing paper is pretty cool, but the idea doesn’t seem to really fit with a type-driven workflow (ie. for design and refactoring support).
Fair enough. My actual view is somewhat more nuanced. I don’t believe that erased types are workable either, which I bet is a big part of the problem in Erlang. I also want reflection, contract enforcement, and other runtime services.
1
2
Erasure should be possible, but so should reification, so you can get zero-cost when compiled, or usable at runtime for parsing and value generation. The language has to be codesigned with its type system (and VM too!)
2
1
Show replies