Other ways to replace a table row? – JavaScript – SitePoint Forums


fetch() is not always AFAIK reliable because it is asynchronous. I’ve been trying to edit and replace a table row reliably for a few days and found this way to replace a table row. Maybe reliable?

  1. Edit record
  2. fetch record with delay
  3. update table
async function update_sql(url, json) {
  let body = get_updatebody(json)
  let obj = JSON.parse(json);
  let id = obj[mod_id]
  await fetch(url, body)
    .then(response => (response.json())) //no return values

function get_newrow(id) {
  setTimeout(function() {
    let url = "https://api3.go4webdev.org/" + mod + "/id/" + id;
      .then(response => response.json())
      .then(newdata => replace_tablerow(newdata))
  }, 250);

function replace_tablerow(data) {
 let row = document.querySelector('table tr[data-id="' + data[mod_id] + '"]');
 for (let key in data) {
    let val = data[key];
    let cell = row.querySelector('td[data-key="' + key + '"]');
    if (cell) cell.innerHTML = val;

Theoretically I can modify and send return values, but that only seems to result in object.Promise answer. I think it’s not reliable at all…

  1. Edit record and send return values
  2. Replace table row with returned values


  1. Is there an even more reliable way to edit a record and update the table row with new values?
  2. Is there a way to read return values ​​in Javascript and update a table row?
  3. Are there other ways to do this that are even simpler?

I don’t understand at all what you want to do?

What does “Modify Data” mean? Who modifies the data? Where is it published?

Why shouldn’t fetch be reliable just because it’s asynchronous?

A timeout is never a good idea for controlling asynchronous tasks.

He found a partially proper solution to the problem and asks us for advice on how it could be done more properly without the hack of using the delay.

1 like

#1 I don’t know how it follows. Asynchronous vs. synchronous does not make something more or less reliable; it is a web connection between the browser and the web host. If the host is unreliable, it’s not the research’s fault.

#2 You are awaiting the first fetch, so it’s no longer asynchronous. You force it to be synchronous. Why don’t you wait for the new row to be fetched, I don’t know, but you chose to make it asynchronous.

mod is undefined, but I assume you have it defined elsewhere, otherwise javascript would yell at you in the console. Why do you use mod here, but the mod_id of the JSON everywhere else I’m not sure. Are you sure that’s not your problem? Do you cause a race condition somewhere to set the value of mod?

Select a row, modify the record in the database, and update the selected row.

Edit, update or modify a record in a database.

Fetch() is executed, but you can’t expect the result to be ready to use. It’s AFIAK just a “promise” to deliver data. And sometimes the recovery doesn’t always keep the promise because it takes longer etc.

You hit the nail on the head. That’s why I ask :slight_smile:

Fetch() does not provide an AFAIK “ready” state. So I can’t check if the record is saved before using it (?). By removing the delay, it recovers the old record. The update is not fully registered.

The critical part is checking that the record is saved correctly so that I can use it to update the table row. I do not know if async await fetching the updated record makes a difference (?)

It’s an attempt to make it generic. fashion and mod_id is defined at the page level (global) and is used to represent usr (table) and user_id (table column primary key) (or tsk and tsk_id for another window).

then is a “completed” status for the request you sent. If your receiving site also performs asynchronous tasks to store the record, there must be a job completion API for that job, and the remote server must provide a job reference id so you can check the status validation; you shouldn’t shoot the record only on a randomly determined timer.

So why use data[mod_id] in the replace_tablerow? This does not refer to your aggregate information, but to what you retrieved from the server request…

An example ?

let row = document.querySelector('table tr[data-id="' + data[mod_id] + '"]');

means “find and get a reference for this row using data-id: usr_id=2”. Any better suggestions?

I’m still confused.

somewhere in your code you are sending an asynchronous fetch to store the changes in the database. This query will return a promise. In the promise resolution, you can be sure that the new data is stored. So now you can call the update table and it will of course fetch the new data. (Even if it’s not necessary because you’ve already sent this data to the server, so why retrieve the same data?)

Not a direct example, but how it would normally work in case a server takes asynchronous jobs:

The client sends: “Do this please. Here is the data for ID 9876.”
Server sends: “I’m working on it. Job ID 1234.”
Client sends: “Checking job ID 1234.”
The server sends: “In progress”.
Client sends: “Checking job ID 1234.”
The server sends: “Task completed”.
(At this point the client knows the work is being done on the remote server; what they choose to do at this point is up to them, but in your case it would look something like)
Client sends: “Get record 9876”
Server Submissions: Record information 9876.

If this is what your remote server is doing, this is how I would expect the stream to go; you question until you see the job is done, then you can act on it. I don’t know what service you’re calling with that URL, so I don’t know if that’s what’s happening. It seems that’s what you’re suggesting, because otherwise you wouldn’t need a delay at all.

I don’t see any benefit to this dual asynchronous tasks. If the client does not wait for the server to finish, the server must not return until it has finished. Anything else will lead to such a very awful poll structure which I would always try to avoid.

But why doesn’t it work immediately?

That’s a very good question. I don’t have a ready answer to this :slight_smile: Other than that confirms that the recording is saved correctly.

If you are running an API for database storage for many clients, you may want to store tasks asynchronously rather than handling each request synchronously and potentially allowing a connection to interrupt your service for d other issuers.

If I am sending the API 5 GB of data, or a complex request that will consume processing time, you want to be able to continue processing other requests while the work is done in the background.

I don’t know what language/framework is not able to handle multiple requests in parallel without completing the first one, but I would never use it :slight_smile:

My advice then would be to never host an API-based data storage solution. raise your shoulders

So I interpret that you are suggesting a loop that checks for example that a timestamp is edited and recorded on the record?

I’m suggesting that if the server isn’t making your requests synchronously, you’re missing a step in the process. Without the service documentation, I can’t give a direct answer.

If it’s making the request synchronously, then there would be no need for any delay, you’d just send the update, and as soon as it’s done, send the select (you’re probably doing this to check that the server has been updated successfully; you already have the data to put in the line, because you are the one sending it to the remote server).

Maybe you can start by telling us which backend and which framework you are using to store the data?

I use Go + Vanilla JS, CSS and HTML (no framework)

API is 100% Go (no framework)

And the database is Postgresql using the built-in JSON functions. (A touch of NoSQL)

I have no knowledge of GO so can’t help much here…

Can you show me how you call REST API to store changed data in your JS code?


Comments are closed.