Skip to content

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

Open
wants to merge 17 commits into
base: 5.7.x
Choose a base branch
from
Open

Reactive View Rendering #985

wants to merge 17 commits into from

Conversation

sdelamo
Copy link
Contributor

@sdelamo sdelamo commented Feb 18, 2025

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

@sdelamo sdelamo requested a review from yawkat February 18, 2025 11:55
@sdelamo sdelamo changed the title Reactiveviewrendering Reactive View Rendering Feb 18, 2025
Comment on lines +102 to +103
Collection<ViewsRenderer> viewsRenderers = beanContext.getBeansOfType(ViewsRenderer.class, Qualifiers.byTypeArguments(bodyClass, Object.class));
return beanContext.getBeansOfType(ReactiveViewsRenderer.class, Qualifiers.byTypeArguments(bodyClass, Object.class, Object.class))
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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?

@sdelamo sdelamo requested a review from graemerocher February 19, 2025 16:29
Copy link

StringBuilder sb = new StringBuilder();
RenderCallback cb;
try {
cb = beanPool.useContext(handle -> render(viewName, props, sb, handle.get(), request));
Copy link
Contributor

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().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support async views rendering
4 participants