-
Notifications
You must be signed in to change notification settings - Fork 125
Fix runtime renderers rendering of certain sections #2674
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
Conversation
@@ -145,7 +145,7 @@ abstract class RendererBase<T> { | |||
Template _template; | |||
|
|||
/// The output buffer into which [context] is rendered, using a template. | |||
final buffer = StringBuffer(); | |||
StringBuffer buffer = StringBuffer(); |
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.
Why can we not pass buffers into the RendererBase and share them, rather than requiring them to be different for each object? Or, further, maybe this could be part of the idea @kevmoo suggested of just having a stream that we add to.
I'm OK with a big honking TODO/issue filed on cleaning this up, but I think the need for a withBuffer
really points to a refactoring using streams being the way to handle this.
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 don't think there is any need for an asynchronous stream API. I've added a TODO to pass around a single StringBuffer.
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.
Oh, I was thinking StreamSink accessed synchronously. Async definitely seems like overkill.
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.
Ah interesting.
If a section is found which is keyed on a context variable other than the top of the stack, then the wrong buffer will be written to.
Before this fix, the test added in this PR renders "Text TwoOne ". Yikes!
It looks like
section()
is the only node to refer toparent
in this way. (getProperties()
does not touch its ownbuffer
; it only returns a result directly.)