-
Notifications
You must be signed in to change notification settings - Fork 34
Reactive View Rendering #985
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 5.7.x
Are you sure you want to change the base?
Conversation
reactive onErrorMap
reactor test in libs.versions.toml
views-core/src/main/java/io/micronaut/views/reactive/DefaultReactiveViewsRendererLocator.java
Outdated
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/DefaultReactiveViewsRendererLocator.java
Outdated
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/ReactiveViewsRendererAdapter.java
Outdated
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/ReactiveViewsRendererAdapter.java
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/ReactiveViewsRendererFactory.java
Outdated
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/ReactiveViewsRenderer.java
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/ReactiveViewsRenderer.java
Outdated
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/ReactiveViewsRenderer.java
Outdated
Show resolved
Hide resolved
views-core/src/main/java/io/micronaut/views/reactive/DefaultReactiveViewsRendererLocator.java
Outdated
Show resolved
Hide resolved
Collection<ViewsRenderer> viewsRenderers = beanContext.getBeansOfType(ViewsRenderer.class, Qualifiers.byTypeArguments(bodyClass, Object.class)); | ||
return beanContext.getBeansOfType(ReactiveViewsRenderer.class, Qualifiers.byTypeArguments(bodyClass, Object.class, Object.class)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sdelamo can you look at splitting this so we are not adding reactive overhead unnecessary for non-reactive view renderers?
|
StringBuilder sb = new StringBuilder(); | ||
RenderCallback cb; | ||
try { | ||
cb = beanPool.useContext(handle -> render(viewName, props, sb, handle.get(), request)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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()
.
Close: #857
@yawkat @mikehearn I added a
ReactiveViewsRenderer
API and changedReactViewsRenderer
to implement it. I added a method namedcomplete
to the callback class to complete it. The callback class is now aCompletableFuture
. 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