workflow-kotlin
workflow-kotlin copied to clipboard
Published
20 hours ago •
square
square
Compose in the Runtime Take 3
OK so I have updated this with a recent commit that isolates all of teh Compose optimizations as a plugin module
- Trying to call into the Compose runtime directly (without it being a Composable) was a dead end for now as I worked on it for a bit with Zach and we got past his knowledge and idea of where to go next, so letting that go. The impact of this is we need a StatefulWorkflow/StatelessWorkflow extension to add the @Composable Rendering - but I think i did that relatively nicely.
- This update is passing all the tests locally and is behind a warning annotation.
- You would add the workflow-core-compose module and plugin the optimization to the runtime when calling renderWorkflowIn, as I do in performance poetry (and it shows the same rendering oprtimizations on the tests).
- I like where this is at for pausing as its all isolated and I could likely rebase this without too much difficulty. (Obviously it doesn't have any compose runtime specific tests yet so I would want to add that when picking it back up).
- Unfortunately I had to pull all of our runtime.internal classes into public land because we (still I think?) don't have good 'friend path' support for kotlin modules - and since I'm extending them all in the compose-core module I need access.
- What I would like to do with this is turn off the publishing of these and the explicit API mode. So they can still be public for the other module but won't be part of the published API (haven't done this yet). Unless someone has a good idea for package-protected in kotlin?
- Some of the polymorphism got a bit messier than at other times - would really appreciate ideas as to how it could be cleaner at points. WorkflowNode initialization is really the ugliest one as I had to add a startSession so that the initialization happens after the child class is instantiated and not just after the parent class.