Last year I wrote a blog about how to create editable tables based on version 6 of JET. That entry has been quite popular, but since the publishing of that blog things have changed in both Oracle JET and Oracle Visual Builder, and there is a new pattern we are now recommending for handling editable tables. The new pattern is offering better performance and eliminates some refresh issues that users encountered with the old approach. Below you can see a demo showing how to build an editable table in VB from scratch following the approach shown in the JET 8.1 cookbook sample.
Note - In general our UI expert are not in favor of editable tables, especially if your users would end up using their application on a mobile device with touch gesture. A better UI pattern they would recommend is editing in a pop-up or in a form next to the table. Here is a blog about editing from a pop-up - which is also simpler to implement :-) .
A few points about the solution:
The table should only show input component for the row you are currently editing. This is mainly for performance reasons. Rendering multiple lines with input components in them is a heavy task for the browser, and using just one line for editing reduces the time and memory needed to accomplish page rendering.
The table is based on an ArrayDataProvider - a variable that keeps an array of the records being edited on the client - allowing you to modify them over time (unlike ServiceDataProvider). Note that in the new March version of Visual Builder (19.4.3) we updated the ADP implementation so in the source you'll see this as "type": "vb/ArrayDataProvider2".
The actual editing is done on an object that replicates the current row being edited - this way when you change values we don't need to refresh the full array on each field change. Once you are done with the editing of the row, we update the array of records modifying just the row that you changed. We leverage two events on the table to catch the beginning and end of the row editing process.
The demo shows one approach to saving the data to the backend - sending a REST call to the backend to update each of the rows from the array. This of course is not the recommended approach - since you can be much more efficient sending just the rows that changes, and batching those transactions into a single REST request. I'm planning to have another blog entry showing this approach in the future. Another approach you could take is to send an updated row to the backend immediately as you leave the editing mode. This is assuming your use case is ok with this immediate commit without an additional operation by the user (such as clicking a save button).
Here is the full process end to end:
If you are looking to skip some parts then the flow is with time stamps so you can fast forward to the parts you need: