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

fetch() will not be at all times dependable AFAIK as a result of it’s async. I’ve tried to edit and exchange a desk row in a dependable manner for some days and located this strategy to exchange a desk row. Possibly dependable?

Edit document
fetch the document with delay
replace the desk

async perform update_sql(url, json) 
  let physique = get_updatebody(json)
  let obj = JSON.parse(json);
  let id = obj[mod_id]
  await fetch(url, physique)
    .then(response => (response.json())) //no return values
    .then(get_newrow(id));
  end()
  tippy2()


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


perform replace_tablerow(information) 
 alert(JSON.stringify(information))
 let row = doc.querySelector('desk tr[data-id="' + data[mod_id] + '"]');
 for (let key in information) 
    let val = information[key];
    let cell = row.querySelector('td[data-key="' + key + '"]');
    if (cell) cell.innerHTML = val;

Theoretically I can edit and ship return values, however this solely appears to end in object.Promise reply. I interpret that this isn’t dependable in any respect…

Edit document and ship return values
Change the desk row with returned values

Questions:

Is there a much more dependable strategy to edit a document and replace the desk row with new values?
Is there a strategy to learn return values in Javascript and replace a desk row?
Is there another methods to do that which are even easier?

I completely don’t perceive what you need to do?

What means “Edit information”? Who’s enhancing information? The place is it edited?

Why ought to fetch not being dependable solely as a result of its async?

A timeout isn’t ever a good suggestion in controlling asynchronous duties.

He has give you {a partially} appropriate resolution to the issue, and is asking us for recommendation about the way it may be carried out extra suitably with out the hack of utilizing the delay.

1 Like

#1 Undecided how that follows. Asynchronous vs synchronous doesn’t make one thing roughly dependable; it’s an online connection from the browser to the online host. If the online host isnt dependable, thats not fetch’s fault.

#2 You’re awaiting the primary fetch, so its not asynchronous anymore. You’re forcing it to be synchronous. Why you’re not awaiting the newrow fetch, i dont know, however you’ve chosen to make it asynchronous.

mod is undefined, however i’ll assume you’ve outlined it elsewhere, in any other case javascript could be screaming at you within the console. Why you utilize mod right here, however the mod_id from the JSON in every single place else, i’m unsure. Are you certain this isnt your downside? Are you inflicting a race situation someplace to set the worth of mod?

Choose a row, edit document in database and replace chosen row.

Edit, replace or modify a document in a database.

Fetch() is executed, however you can not count on the outcome to be prepared to make use of. It’s AFIAK only a “promise” to ship some information. And generally fetch doesn’t at all times retains the promise because it takes longer time and so on.

You hit the nail. That’s the reason I’m asking

Fetch() doesn’t ship a “prepared” state again AFAIK. So I can’t test if the document is saved earlier than I exploit it (?). Eradicating the delay it fetches the outdated document. The replace will not be absolutely saved.

The important half is to manage that the document is correctly saved so I can use it to replace the desk row. I have no idea if async await fetching the up to date document makes any distinction(?)

That is an try and make it generic. mod and mod_id is ready on the web page stage (world) and are used to symbolize usr (desk) and user_id (desk column main key) (or tsk and tsk_id for an additional window).

then is a “accomplished” state for the request that you just despatched. In case your receiving website can be doing asynchronous duties to retailer the document, then there must be a job-completion API for that job, and the distant server must be serving a job reference identifier so that you can test the standing of the commit; you shouldnt be pulling the document simply on a randomly decided timer.

Then why use information[mod_id] within the replace_tablerow? That’s not referencing your world data, it’s referencing what you bought again from the server request…

Any instance?

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

means “search and get a reference for this row by utilizing data-id: usr_id=2”. Higher solutions?

I’m nonetheless confused.

someplace in your code you ship am async fetch to retailer the adjustments within the database. This request will return a promise. Within the resolve of the promise you might be certain, that the brand new information is saved. So now you’ll be able to name the replace desk and it’ll, after all, fetch the brand new information. (Even when this isn’t obligatory as a result of you have already got this information ship to the server, so why get the identical information again?)

Not a direct instance, however how it could work usually within the case the place a server was taking asynchronous jobs:

Shopper Sends: “Do that please. Right here is the info for ID 9876.”
Server Sends: “Engaged on it. Job ID 1234.”
(pause)
Shopper Sends: “Checking Job ID 1234.”
Server Sends: “In Course of.”
(pause)
Shopper Sends: “Checking Job ID 1234.”
Server Sends: “Job full.”
(At this level, the consumer is aware of the job is finished on the distant server; what they select to do at that time is as much as them, however in your case, it could seem like one thing like)
Shopper Sends: “Get document 9876”
Server Sends: Document 9876 data.

If that’s what your distant server is doing, then that’s how i might count on the move to go; you ballot till you see the job is finished, after which you’ll be able to act on it. I dont know the service you’re calling with that URL, so I don’t know if that’s what’s taking place. It appears to be what you’re suggesting is going on, as a result of in any other case you wouldnt want a delay in any respect.

I See no benefit on this double asynchronous duties. If the consumer will not be ready for the server to complete, the server should not return earlier than he has completed. Every little thing else will result in such a really terrible polling construction which I’d attempt to keep away from at all times.

However why does it not work with out the delay?

That could be a excellent query. I’ve no prepared reply to that Aside from it confirms that the document is saved correctly.

Should you’re operating an API for database storage for a lot of shoppers, you could need to asynchronously retailer jobs reasonably than dealing with every request synchronously and doubtlessly permitting one connection to halt your service for different transmitters.

If I ship the API 5 GB of knowledge, or a fancy question that’s going to eat processing time, you need to have the ability to nonetheless discipline different requests whereas the job chunks away within the background.

Undecided which language/framework will not be in a position to deal with a number of requests in parallel with out ending the primary one, however I’d by no means use it

My recommendation could be to by no means host an API-based information storage resolution then. shrug

So I interpret that you just counsel a loop that checks for an instance a time stamp is edited and saved on the document?

I counsel that if the server ISNT doing all your requests synchronously, you’re lacking a step within the course of. With out the service’s documentation, I can’t give a direct reply.

If it IS doing the request synchronously, then there wouldnt be a necessity for a delay, you’ll simply ship the replace, and as quickly as it’s carried out, ship the choose (presumably you’re doing this to confirm the distant server has been up to date efficiently; you’ve already bought the info to place into the row, since you’re the one sending it to the distant server).

Possibly you can begin by telling us which backend and framework you’re utilizing to retailer the info?

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