-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Added CellRenderers #748
base: master
Are you sure you want to change the base?
Added CellRenderers #748
Conversation
Thanks for this PR, and apologies for taking so long to respond! I'm weighing the complexity of merging this PR and maintaining the documentation etc, as compared to recommending that developers do something similar to the Heatmap and Barchart renderers, which basically walk the output of the Table Renderer and tweak the DOM. |
I've struggled with this decision myself. I appreciate the separation of concerns of the layered renderers. But in the end, I was frequently writing encoded "hints" to the cells just remove and translate then to the good stuff in the next step. It felt inefficient and it was harder to reason about. Particularly when you start doing "fancy stuff" with aggregators and labels, using plain text to bridge the communication with the renderers was a pita. I believe that the concept is easy enough to explain, its basically a hook to the last mile of the table renderer and the cell renderers are just functions to map some context to an html element. As soon as I figure out how to make contributions to the wiki I could write a couple of paragraphs explaining the feature. |
Interesting. Tell me more about the "hints" you were using?
Regarding documentation, I should really get around to making a page about
rendererOptions :)
N
…On Thu, Sep 21, 2017 at 20:48 svpace ***@***.***> wrote:
I've struggled with this decision myself. I appreciate the separation of
concerns of the layered renderers. But in the end, I was frequently writing
encoded "hints" to the cells just remove and translate then to the good
stuff in the next step. It felt inefficient and it was harder to reason
about. Particularly when you start doing "fancy stuff" with aggregators and
labels, using plain text to bridge the communication with the renderers was
a pita.
I believe that the concept is easy enough to explain, its basically a hook
to the last mile of the table renderer and the cell renderers are just
functions to map some context to an html element. As soon as I figure out
how to make contributions to the wiki I could write a couple of paragraphs
explaining the feature.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#748 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMbA-VN5D0JWdc72i3bCCBi7LVtCHeJks5skwPYgaJpZM4Oe7my>
.
|
CellRenderers can be used to define cell level customization to the default Table Renderer. Workaround for issue #707.