A modern programming language that makes developers happier.

kotlinlang

Upon upgrading http4k to v6, I've noticed that with `RequestContextKeys` being replacing by `RequestKeys` ,I no longer need to pass around a shared context and initialize the server filter stack with the context.  Super happy with that!

You can blame <@U0E2MNCPN> for his constant moaning until we did it :rolling_on_the_floor_laughing: 

I just finished this refactor as well.

When I was first learning http4k, I struggled to keep track of how context and the request were handled separately. The new API feels much more intuitive. Huge thanks for the change! :http4k: :heart:

Yes.  <https://www.http4k.org/howto/attach_context_to_a_request>

Can you just change this:
```    val contexts = RequestContexts()
    val someKey = RequestContextKey.required<Foo>(contexts)
    val otherKey = RequestContextKey.optional<Bar>(contexts)```
to:
```    val someKey = RequestKey.required<Foo>("some")
    val otherKey = RequestKey.optional<Bar>("other)```
and remove `ServerFilters.InitialiseRequestContext(contexts)`?

Yeah, I think that's all you need to migrate

A difference is that you have to specify a name now. Did it generate one before?

I'll let <@U4H0M349G> answer that.  My guess is it's a new requirement now that the `RequestContexts` is eliminated.

it did (overrideable) generate one before because you were forced to use the same key. now we just use the name of the key inside the map so you don't need to pass it around. this is simpler, although potentially less safe

(but you can also pass the keys around as before)

Would it be possible to do it like Java's ThreadLocal, where the key is unforgeable (based on object identity)?

<https://coderanch.com/t/406388/java/Strings-poor-substitutes-capabilities>

What does it mean for a RequestKey to be required? We cannot statically guarantee that it will be there, can we?

It means that at that point of the code you're confident the value is there and want things to blow up if the assumption is false.

That follows a similar logic as any required lens for the request, as we also can't guarantee fields are appropriately set in the incoming request.