description of the layers from slack

[captaincaius]

maybe if i explain it this way it'll help... my vision of hipthrusts is several layers...

1. the bottom enforced-lifecycle-methods layer - at this layer, a class needs to define EVERY lifecycle-stage as an instance method so that an express/whatever handler can be made from it.

THAT original PR uses ONLY the bottom layer
with the bottom-layer, we've gained a) enforced security b) some free error handling c) some nice separation of concerns

but what we've lost is this... a) it's still quite procedural and not declarative - all we've done is split one function into 7! b) splitting it up has incurred some cost in terms of extra code and boilerplate c) there's very little reuse - much of that code will be identical for other request handlers!
So that's why we have the next layer:
2. The declarative class mixers layer - this layer contains:
factories that return
functions that take a class as input and return
subclasses of the class passed in, but with one of the lifecycle methods already defined
😄
layer 2 should give you the ability to have the lifecycle stages defined with all the common things you'd want to do
so far are you following?
for example, a layer-2 factory might give you a function that subclasses a class and adds postAuthorize()
or preAuthorize()
let's be fucking honest...
web developers (backend) have been doing the same exact shit for about 30 fucking years now
99% of our backend has already been done before in one way or another
it's insanity
anyway... using that handler as a testbed, I've already built enough layer 2 so that htUpdateJobOpening ONLY now needs to define doWork(), because the other layer-2 mixers already implemented ALL the other lifecycle stages
only doWork is left
(well... as I said above... you need to split it... but you get what i mean)
anyway... as i was saying... then there's layer-3 ... the composer - the composer just lego's together multiple layer-2 mixers to give you one final mixer ... kind of like rxjs's "pipe"
it's because of layer 3 that we only need to define doWork(), because the pipe already defined all the other lifecycle methods in the superclass
finally there's gonna be layer 4, which we haven't even started yet 😉
also there's little helpers here and there (like the user/role stuff, the mongoose "join" thingie, etc), but they're not super important architecturally