@boris-petrov I think that suggestion makes sense!
Restricting the provider component (and decorator) to only accept explicitly declared keys might help developers catch certain bugs early by warning them when they're trying to use unknown context keys.

The registry is defined the way it is now to make it easier for developers to adopt this addon, though as it matures I can definitely see us switching to more strict types.

Thanks for the answer! I've opened a PR for this. I'm not sure how this index-signature makes it easier to adopt the addon - it only would allow people to make typos that are not caught. Maybe I'm missing something - if you think it's not the right time, you can close the PR or leave it open for later. :)

I'm not sure how this index-signature makes it easier to adopt the addon - it only would allow people to make typos that are not caught

The way it's currently typed makes it easier because a developer doesn't have to add keys to the context registry to use this addon (without typescript complaints).

It's a minor thing, though it does lower the barrier of adopting the addon a little bit. But I agree with you that this is the less type-safe way to do it, as you don't get any hints on whether the keys you're adding are in fact correct.

Ah, I see what you mean. Well, I would argue that if one is using JS only that's not a problem. If one is using TS, they would certainly want more type-safety anyway. But you're technically right so I'll leave the decision whether to merge the commit to you. :)

fwiw, I think this is a good idea, and would love to see the above mentioned PR merged :)