1340: Changing RenderContext from an inner class to a nested class with its own generics

[steve-the-edwards]

Yes, this means we have to provide type parameters every time we use it.

However, it also means we won't break the out RenderingT variance (which will not be allowed come the K2 compiler).

This will fix #1340 as we will no longer be consuming RenderingT (via the Workflow instance to get the PropsT and OutpuT types) when we pass RenderContext into render() as its types - for PropsT and OutpuT will be provided explicitly.

[rjrjr]

Why the StatefulWorkflow prefix in some spots but not others?

[steve-the-edwards]

I think just sloppiness in my regex replacing 🤷🏻

[steve-the-edwards]

I prefer the StatefulWorkfow.RenderContext usage FWIW. but in most cases I think its unambiguous, so no need to be too strict.

[rjrjr]

Will breaking it out allow us to follow up and undo any of the recent c*variance work?

[steve-the-edwards]

Will breaking it out allow us to follow up and undo any of the recent c*variance work?

It's possible we might be able to get in PropsT back. But definitely not out OutputT. as we pass RenderContext<PropsT, StateT, OutputT> as a parameter of render(), which means, by definition the Workflow instance is a consumer of OutputT and it should not be allowed to be covariant across OutputT.

I could do a test bringing back in PropsT.

The other thing this does do though is make RenderingT safe. We would have actually had to make that invariant without this change. So that is already a win!

[steve-the-edwards]

Note also that I can cache RenderContext much more effectively and cleanly now as well - #1342

[steve-the-edwards]

Will breaking it out allow us to follow up and undo any of the recent c*variance work?

It's possible we might be able to get in PropsT back. But definitely not out OutputT. as we pass RenderContext<PropsT, StateT, OutputT> as a parameter of render(), which means, by definition the Workflow instance is a consumer of OutputT and it should not be allowed to be covariant across OutputT.

I could do a test bringing back in PropsT.

The other thing this does do though is make RenderingT safe. We would have actually had to make that invariant without this change. So that is already a win!

Nope. I checked and we can't do in PropsT because of this API in BaseRenderContext:

actionSink: Sink<WorkflowAction<PropsT, StateT, OutputT>>

PropsT is being produced there, so it can't be in PropsT on RenderContext, which means it can't anywhere else.