[VUE #172] A few questions about HotColumn of Vue wrapper

Tags: #<Tag:0x00007fa99aa76390> #<Tag:0x00007fa99aa75a08>

Hi,

The HotColumn is great feature. While I am exploring how to use it properly, I got the following questions.

HandsonTable: 8.0.0-beta.1
HandsonTable/vue: 4.1.1

To my understanding, the HotColumn is just a wrapper of getting the column settings. If there is any ‘hot-renderer’ inside of the HotColumn (children), it will create a renderer wrapper and assign to the “columnSettings.renderer”

  1. One of the great advantage of HotColumn is caching the render result which will improve the performance. My understanding is if we want to use pre-defined cell types, we will lose this feature, correct?

  2. To the customized ‘hot-renderer’, what is proper way of passing additional parameter or props to it? I have tried a few ways, but none of them work. In the ‘getRendererWrapper’, it turns out the prop is {} and all of the standard parameters of renderer is injected through data.

  3. If using the traditional cellTypes or the customized renderer, is there any way to cache the render result?

  4. The columns displayed in our table is generated during the runtime. So, according to my understanding, if there are 12 columns, we can’t use “HotColumn” for just one of them, we need to render 12 "HotColumn"s inside of the “HotTable”, is that right?

Thanks so much,
Jerry

Hi @lijigang.us

that’s a set of pretty advanced questions.

The columns displayed in our table is generated during the runtime. So, according to my understanding, if there are 12 columns, we can’t use “HotColumn” for just one of them, we need to render 12 "HotColumn"s inside of the “HotTable”, is that right?

That’s true, you’re thinking right.

If using the traditional cellTypes or the customized renderer, is there any way to cache the render result?

We do not have any official support for caching but it would be possible by constructing a custom renderer to create a map of values (as a x/y matrix). However, it would only help if you store some calculations that normally are pretty heavy to handle.

One of the great advantage of HotColumn is caching the render result which will improve the performance. My understanding is if we want to use pre-defined cell types, we will lose this feature, correct?

We haven’t noticed a drop in performance with those settings. If it actually does that should be near to undetectable.

I’d need to consult my colleague with the last question. As far as I know, there is no way to attach additional parameters as they’d skipped, but let be double check it.

@lijigang.us,

  1. The component-based renderers have all the advantages of a Vue component, so their performance is really a sum of all the things being done in the component. The wrapper simply takes the component’s DOM output and appends it to the table cells on cell render.
    The pre-defined cell types are simply functions being triggered on each cell render, modifying the cell contents, so you’re correct - there’s no additional logic being done there. (It’s not really a feature of HotColumn though, you can use them globally, without declaring any of the columns)

  2. You’re right, the props object sent to the renderer components is forced to be {}, which I believe is a bug. I’ll give it a look, and if it is, It’ll be fixed with the next release.

  3. I think the answer to 1. describes it - the caching done by the framework is utilized by the component-based renderers. Otherwise, you can try doing some DIY caching inside the renderers, as @aleksandra_budnik described.

  4. That is correct.

Hope this helps!

edit: I did a PR regarding 2.. After this change, it will be possible to pass props to the component-based editors and renderers. Here’s an example:


Is this what you had in mind?

Hi @aleksandra_budnik & @jsiegel
Thanks so much for your quick and detailed answer. It is very helpful. :+1:
Sorry, I was distracted and forgot to check the answer recently.

I’m glad that it was helpful, @lijigang.us guess that we can close the topic but feel free to open a new one when needed.