Update particular cell in Handsontable - javascript

Is it possible to force update only one td (cell) for view ?
There is a method hot.render(), but it rerenders all cells.
I want to update table content JSON data (hot.getData()) using ajax, but I can't find how to force render the table. My table is so huge to rerender each time I receive the data.
E.g.,
$.ajax(url,... ,success: function(d){
var data = hot.getData();
data[parseInt(d['row'],10)][d['col']] = d['value'];
hot.render();//please, change this function into more simple.
},
...
);
is it possible to update a TD-cell at [row,col]?

I agree complete grid rendering is good , however there is one drawback.When we render the complete grid it will scroll back to the row 1 , it will not store the last view we have before render.E.g. i am in the row number 100 as soon as i render grid will come back to row number 1 , now user has to scroll back to row number 100 again which is frustrating.
Any solution to this issue.
I found we could use hot.selectCell(100,1) to go back to row hundred , however how do i store that we were in the row number 100 programmatically, so that i could set it back to that row.
I did one customRendering to change the value of the Grid by using below code, however it has some performance issue when we have large number of row to change.
//Below code will render one row ,similarly apply the loop to modify multiple row.
data.Records[i].Values.forEach(function(value, ix) {
hot.setDataAtCell(i, ix, value);
//i is row number , ix is the column number , v is the new value.
}
However hot.setDataAtCell(i, ix, v) is a costly, so if you have a large number of row then it will hit the performance.However benefit is it will do the custom(single/mulitiple) cell/row rendering without scrolling the grid and preserving the user view.
P.S. in place of hot.setDataAtCell you could use setDataAtRowProp to set the value for a row , however i have not tried.

Re-rendering the entire table is the only way Handsontable will allow you to render and it's there for a few good reasons. First off, it doesn't matter how large your table is since there is virtual rendering in use. This means that it will only render what you can see plus a few more rows. Even if you had trillions of rows and columns, it would still just render enough for you to think it's fully rendered. This is not an intensive task assuming you're not doing something funky with a custom renderer.
The other reason why it renders everything from scratch is that it's Handsontable's way of keeping a stateless DOM object. If you started manually rendering specific cells then you could end up with an out of sync looking table. And, again, since virtual rendering restricts what gets rendered, there's no performance issue associated with a full re-rendering.

You can use setDataAtCell() method to update one or more cells.
setDataAtCell(row, column, value, source)
Set new value to a cell. To change many cells at once (recommended way), pass an array of changes in format [[row, col, value], ...] as the first argument.
Source: https://handsontable.com/docs/7.2.2/Core.html#setDataAtCell
For example:
var row = 3;
var col = 7;
var value = "Content of cell 3,7";
hot.setDataAtCell(row, col, value); // Update a single cell
Method also accepts an array of values to update multiple cells at once. For example:
var cell_3_7 = [3, 7, "Content of cell 3,7"];
var cell_5_2 = [5, 2, "Content of cell 5,2"];
hot.setDataAtCell([ cell_3_7, cell_5_2 ]); // Update a multiple cells
Note that Handsontable documentation does not recommend re-rendering the whole table manually.
render()
Calling this method manually is not recommended. Handsontable tries to render itself by choosing the most optimal moments in its lifecycle.
Source: https://handsontable.com/docs/7.2.2/Core.html#render

Related

AG Data Grid table: generate a Vega-Lite chart that updates automatically

I would like to use Ag Data Grid filtered data to generate plots in Vega-Lite that update automatically whenever the filter(s) are changed. I would prefer to have the implementation in an observablehq notebook. Here is a section on how to access the table data in Ag Grid documentation. I created an observablehq notebook where the chart is updated using a button. There are two issues with this implementation:
The chart is generated only after the button is clicked.
I would prefer the chart update to be automatic without the need to click a button.
Thanks for linking to the notebook! It appears that the angular table does update, but it appends to the element and gets drawn behind the code cells. This is what it looks like in my browser when I move the slider:
The problem with components like this that manipulate the DOM is that they work against Observable's way of managing the DOM. Even if the component were to update correctly, it would probably still not resize the way you'd expect.
Observable is already reactive at its core, which is something angular (and other frameworks like React) was built to add to JavaScript. Using Observable's built-in reactivity will be much easier in the long run than trying to make two different reactivity models work with each other.
You can make the AG Grid table an Observable “view” so that you can both (1) see the table and (2) refer to its value in other cells, which will re-run when you filter the table. Once you do that, it'll work naturally with anything else you want to do in the notebook. Here's a working example with Observable Plot, and here's the same example with Vega-Lite.
Assuming you've loaded AgGrid and have gridOptions in a different cell, you can wrap AgGrid as an Observable view like this:
viewof table = {
const node = htl.html`<div style="height:320px;" class="ag-theme-alpine"></div>`;
new AgGrid.Grid(node, gridOptions);
gridOptions.api.addEventListener("modelUpdated", update) // set value after filter
gridOptions.api.sizeColumnsToFit();
update(); // set initial value
function update() { // for Observable dataflow
let value = [];
gridOptions.api.forEachNodeAfterFilter(d => value.push(d.data));
node.value = value;
node.dispatchEvent(new Event("input"));
}
return node;
}
A few notes on how this is different from your version (as of when I saw it):
I put the HTML and the AgGrid initialization in the same cell, so that AgGrid has an object reference to the node and if you re-run the cell it all gets cleaned up and recreated as a whole.
I listen for when the grid rows change with gridOptions.api.addEventListener("modelUpdated", update).
In that update function, I do the same iteration over the rows that you were doing to build an array, but then I set it as the value of the node, and dispatch an input event from that node. That's what Observable looks for to tell when a view has changed its value and other cells should re-run.
I name the cell viewof table. You might've seen this pattern with sliders and other inputs on Observable. The viewof keyword means that you get the DOM node rendered, but you can also refer to its value with just table in other cells.
Thanks for the question; I’ve been meaning to check out AG Grid for a while!

Ag-Grid row groups rendering bug

I'm only grouping rows on certain values. Here's a simplified version of my database structure:
item
id
parent ID (if this is a child item)
item type (parent, child, normal)
I am grouping when the row's item type is parent. I do a database fetch for that row's children, and populate them in the row group.
I end up with a very strange rendering problem:
(GIF) https://imgur.com/a/8lFVjLn
Here is my code. It's CoffeeScript but should be self-explanatory for those familiar with JS. "?" is just a null check, "#" is "this"
....
# the user has expanded a group, so check that we have parent node data...
else if params.parentNode? and params.parentNode.data? and params.parentNode.expanded
parentId = params.parentNode.data.id
if #editionsDict[parentId]?
params.successCallback(#editionsDict[parentId], #editionsDict[parentId].length)
else
# database call that returns a promise for when data is retrieved
#gridLoadChildren(parentId).then((res) =>
setTimeout(()=>
#editionsDict[parentId] = #childWorks
params.successCallback(#editionsDict[parentId], #editionsDict[parentId].length)
,0)
)
#childWorks is populated in #gridLoadChildren. Other than that, #gridLoadChildren is just a database call that performs a select using the parent ID.
Unfortunately for what I want I could not use Ag Grid's row grouping. The whole time I was working on this feature it felt like I was wrestling with the grid and trying to make it do something it wasn't meant to do. Thankfully, I came across the master/detail documentation and will be going that route instead. So far it works exactly for what I need (server side data and only expanding groups for certain rows).

Practical Javascript MVC example - can the controller directly work on the view or only the model

I am rendering tables using javascript with a model, view, controller, and events.
I need to calculate a sum across table rows and put that value in a 'sum' column. Easy enough....
I can do this in one of two ways:
Using the Controller I can copy the view data to the model, calculate the sum using data stored model and store the sum in the model, then fire an event that the model changed, which the view will pick up and re-render the table.
Or I can directly access the table view from the controller to calculate the sum, and put the sum into the sum column. Then I can copy the view over to the model.
Both methods work, however the first method interferes with the cell focus as the table is re-rendered. On keyup the table is re-rendered. The second method works flawlessly from a user perspective.
My understanding is that the first method is the textbook approach, and it might be incorrect to re-render the entire table, but that was just easier.
here is the code:
//Method 1 - interferes with user input
//controller.copyTable() is already fired onkeyup
controller.model.tdo[row].sizes.data.forEach(size =>{
sum += math.myParseFloat(size);
});
controller.model.tdo[row]['qty']['data'] = sum;
controller.model.modelChanged.notify(); //re-render of the table will occur
//method 2... works like a charm
controller.view.elements[row]['sizes'].forEach(size =>{
sum += math.myParseFloat(size.value);
});
controller.view.elements[row]['qty'] = sum;
controller.copyTable();
Any thoughts? I am thinking working directly on the view is actually better, and it may just be a javascript thing....or maybe i need to re-look at how I re-rendered the table.

Get Row Number with Handsontable

Super noob question here. I have an array of row indexes that I would like to use to change the color of my Handsontable rows. I figure HOT would provide a method to retrieve the tr element of a table with something like hot.getRow(5), but it doesn't seem to exist.
So in a nutshell I'm trying to do this
var rowIds = []
$.each(rowIds , function (i, element) {
var row = hot.getRow(i);
$(row).closest('tr').css('color','green');
});
I've found I can use getCell() method which accepts a row and column # along with a boolean, but using this would require extra code for something that should be as simple as passing a single argument. Is there a method I'm overlooking or is this the only way?
Here's the thing with how HOT works: it is a JS object which renders a stateless DOM table. This means you should never EVER try to manually modify the HTML of your table. Even if you did want to do that, as soon as you make a change to those green cells, they would get re-rendered, not green.
Instead, you want to use the readily accessible 'custom renderers' that are associated with each column or cell, depending on how you define them. These are applied just like the data attribute in the columns or cells definition. They are functions and here's an example:
function greenCellRenderer(instance, td, row, col, prop, value, cellProperties) {
Handsontable.renderers.TextRenderer.apply(this, arguments);
td.style.color = 'green';
}
You should read up on the full documentation to understand the full power of the renderer but it's pretty clear from the arguments it takes what you can do. One thing you would be able to do is apply the green color you're hoping for. Of course to selectively do this you would either apply the renderer to specific cells, or put a conditional inside this general renderer using the row and col arguments to your advantage.
Hope that helps!

Working with a huge state object

I have a problem with handling state in a React application. For some background: The application mostly renders a big table with lots of data that is then editable. The data comes from a single source as a big list of objects (actually it’s a more complicated hierachy but let’s keep it simple for this purpose), and should be kept as it is. Users can then partially change the data in the big table, and ultimately save their changes.
Since the data comes from a single source, I’m thinking in React and store the data as the table state and pass everything necessary down to the individual components. So a row gets only the row data as a prop, and the cell gets only the cell data as a prop. For the update process at cell level, I then use an inverse data flow to call an update method on the table that updates the state for the updated cell:
change (rowIndex, cellIndex, value) {
this.state.data[rowIndex][cellIndex] = value;
this.forceUpdate();
}
This works pretty fine in theory. However, I have a lot data; the table easily contains about 1000 rows with multiple columns. This is not a problem directly: it takes a bit time for the browser to render the table, but once it’s there, it can work with it pretty well. Also, React doesn’t have a problem with that data amount either.
But the problem is that changing a single cell essentially triggers a rerender of the whole table. Even if the DOM is only changed for a single cell as a result, all the render methods are executed with most of them not doing anything (because the change only happened in a single cell).
My current solution is to implement shouldComponentUpdate for the row component and perform a deep check on all mutable values to avoid a rerender at row and cell level. But this feels very messy as it’s not only very verbose but also very dependent on the data structure.
So I’m not really sure how to tackle this better. I’m currently thinking about moving the state into the rows, and as such also the mutation functionality, and have the table component query the rows for changes on demand. Alternatively I could also move the whole data out of the table, and only work with identifiers the rows then use to query the data from a central store that provides the data and also offers mutation functions. This would be possible because the whole data is loaded once on page load, and then only mutated by the user.
I’m really unsure on how to handle this situation. I’m even thinking of dropping React for this, and rendering everything as static HTML with a custom JavaScript module on top that fetches the data on-demand from the actual input elements when a save is requested. Is there a way to solve this in a good way?
In case you want to play around with this situation, I have a running example on CodePen. As you type into one of the many input fields, you will notice a lag that comes from React calling all the render functions without really changing anything in the DOM.
You should take a look at PureRenderingMixin and shouldComponentUpdate documentation
I made some changes to your code so you don't modify state directly so shouldComponentUpdate can properly compare the props to determine if a rerender is required. The code here is a bit messy and I hacked it together really fast but hopefully it gives a good idea of how it could be implemented.
http://codepen.io/anon/pen/yYXbaL?editors=001
Table
change (rowIndex, cellIndex, value) {
this.state.data[rowIndex][cellIndex] = value;
var newData = this.state.data.map((row, idx) => {
if(idx != rowIndex){
return this.state.data[idx]
} else {
var newRow = this.state.data[idx].map((colVal, idx) =>{
return idx == cellIndex ? value : colVal
})
return newRow
}
});
Row
shouldComponentUpdate(nextProps){
return this.props.cells != nextProps.cells;
}

Categories