Reactive View Rendering

[sdelamo]

Close: #857

@yawkat @mikehearn I added a ReactiveViewsRenderer API and changed ReactViewsRenderer to implement it. I added a method named complete to the callback class to complete it. The callback class is now a CompletableFuture. As the write method in the callback can be invoked multiple times we need a way to know the work has finished. Thus, with this change, the javascript is responsible for completing the callback.

@PepeBotella25 I wrote a PR with how it would look like with your sample app: PepeBotella25/micronaut-ssr#2

[graemerocher]

think it would be better to remove the generics and add a supports(Class<?> type) method to the ReactiveViewsRenderer rather than 2 getBeansOfType calls which looks like a hack

[sdelamo]

I agree it is hackish. But we need to call twice because many ReactiveViewsRenderer implementations are backed by a ViewsRenderer, the ones using ReactiveViewsRendererAdapter.
For those implementations, we need to know if the delegated class supports the body class.

Note, that the lookup cost for the appropriate view renderer for a particular body class is paid only once as it is cached in a map.

[graemerocher]

ok but I am unconvinced wrapping the non-reactive in a reactive API by default is the way to go. The Writable part not being shifted to the blocking thread pool is a problem

[graemerocher]

it would be better to leave the ViewRenderer stuff as is and add an optional interface ReactiveViewRenderer that can be implemented by the view renderers that support it and then adapt the code with different if/else blocks the adding reactive overhead to all view renderers and changing the behaviour of Writable

[graemerocher]

@sdelamo can you look at splitting this so we are not adding reactive overhead unnecessary for non-reactive view renderers?

[sonarqubecloud]

Quality Gate passed

Issues
23 New issues
0 Accepted issues

Measures
0 Security Hotspots
70.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mikehearn]

I'm not sure this line is correct. Won't this release the context back to the pool when render returns, but now render is async the context should be kept open until the moment the callback is finished. At the moment no test will reveal the problem because it will only happen if you actually use await inside a render script.

I think rather than useContext the handle should be obtained using BeanPool.checkOut and then the returned handle can be closed inside the implementation of callback.complete().