Using AJAX or something else, is there a way to have records update automatically when changed?

AJAX updates on-the-fly without page refreshes. So a user can go through multiple pages of information on what is effectively the same page, like so:

My question is this: If two users are modifying records in a table like this, and one edits a field, then exits that field while it is set to auto-save once that happens, does the field update for the other user without them having to refresh their page?

I’d guess the tables’ information is put in client memory once the page loads, so the records wouldn’t update like that, but I have no working examples to test this with.

If it won’t do that natively, is there a way to make it do that with some other feature of JavaScript?

Sooooo, you want to rebuild Google Docs :stuck_out_tongue:

Yes it’s possible, no it isn’t easy and look at websockets because then you can push the change to every other connected client :slight_smile:

It’s true that it is first put into memory, but noone is stopping you to send the change to the server in your autosave function :wink: Once it’s on the server you just need a way to push it to all other clients, and that’s where websockets come in.

1 Like

Uh, yeah basically. Ideally.

Neat. Will look into it.

Yeah, by “autosave” I mean updating the record in the database on the server.


I thought so :wink: But since it’s already hitting the server you just need to send it back out to all currently connected clients.

1 Like


Laravel has support for WebSockets. Neat.

If you’re interested I think I still have a decently broke github repo somewhere that’s an SPA framework that uses AJAX and Jquery and passes back and forth with PHP.

It doesn’t have websocket integration, but I was getting ready to code it in before I got too busy to work on it anymore.

1 Like

Sure, I’d be interested in looking at it if you don’t mind. Thanks.

Here ya go:

Like I said it’s super broke right now. I’d be more than happy to explain how I did etc if you have any questions – my comments are pretty bad.

1 Like


I mean…

echo “nop”;


Thanks, this will be educational for me. I might have issues applying things I learn here to Laravel, but I think it’s just as important to learn a framework’s underlying things as it is to understand how the framework itself handles the interactions between the different technologies it uses.

Lol it’s a random password since it was a dev DB.

Anyway, Laravel is just a framework for PHP so most of it should still work the same.

1 Like

If you can’t or don’t want to use WebSockets in a project you can also set an interval to call the server for changes and apply them. It wouldn’t be a 100% live for every connection, but it would work for older browsers without WebSocket support.

But please, for the love of all that is holy, don’t use setTimeout() or setInterval() for that (or rather only as a fallback) and use requestAnimationFrame() instead. Obviously detect if it’s supported (because chances are requestAnimationFrame() isn’t supported either if WebSocket isn’t supported), and if not resort to the former as a last resort because it’s basically terrible.

Though non of that should be an issue if you’re doing a reasonably recent deploy.

Still bad practice thought :stuck_out_tongue:

1 Like

Please stop spreading vulnerable code to newbies

? He fully disclosed it was broken to begin with.

This gets really interesting when you have two people editing a field at the same time :wink:

It wouldn’t be syncing their edits. Just what is committed. Figuring there’s an auto-save when the field is done being edited (i.e. the user selects another field or hits escape or whatever), that’s when the change is actually committed.

If someone else is also editing the same field but hasn’t committed yet, I can do a couple things to alleviate issues.

  1. Have the update get pushed to their client anyway, but as a popup letting them know someone else has changed the field while they were editing it.
  2. Check if the field changed when the user tries to commit and do the same thing (let them know)

I can’t think of another way that works better or as good as those two.

When either of those happen, I’ll just give the user 3 options.

  1. Lose their edit in favor of the other user.
  2. Overwrite the other user’s edit with their own.
  3. Merge the two and commit that.

I figure that should handle most things. This is something that 60 people would be using, at most, with 10,000+ records and only certain people who will always be near each other likely to access the same thing at the same time.

I can… just don’t let a second person edit in the first place.
When someone starts editing you tell all other clients to lock the field, making it non-editable, or read-only, however you want to call it.

I don’t know how big your fields are, but writing a custom merger is probably a pain in the rear.

:thinking: Not sure why I didn’t think of that.

The issue I’m solving by producing this website is that we currently use Microsoft Access to directly access, view, and edit these database records. When one person has a record locked for editing, and another tries to sort, or something similar, it locks up the whole database.

It isn’t a good thing for so many reasons. But legacy stuff yo.

Good idea. I’ll probably just do that then.

I was just going to take whoever went first’s edit -> append whoever went second -> commit that and have a note saying to reconcile manually between the two people. i.e. one calls the other and they decide what the field should actually be or something.

Most fields are gonna be simple things like a state, status, date, or other repeatable items. The only field I would’ve expected the merge to matter much on would be the comment fields for obvious reasons.

Aha! Using a mutex to lock each field! But now you have to ask the server for permission to edit any field and your app is slow :slight_smile: Tradeoffs…

There’s always going to be tradeoffs when multiple people are working on the same stuff, not just in documents, but turns out IRL as well :wink:

I actually never checked how google docs does it… never really used it anyway.

Also you don’t need to ask the server for permission if you make the text field itself read-only :slight_smile:

    <input type="text" name="whatever" value="whatever" readonly>

And when the save returns that it’s been successful you remove the attribute.

Effectively you have to ask the server. Because if two people start editing a field at the same time, both are able to start the edit before the server has told them the other person is editing the field.

It’s mostly okay because you don’t have to wait for an answer, so you can assume that nobody else is editing the field until the server tells you otherwise. But then can you make the same assumption when committing?