2
  • Let's say we have a web app that only has one element, for example an image IMG1 and if an user clicks on it, it will change to another image IMG2 (this change should be visible only to the users that clicked and triggered the event).
  • Then, I have another event that triggers when a total of 100 users clicked on the image (or any other back-end related event), and this time I want to dynamically change the image to IMG1 (but now I want the change to happen and be visible to all the users of the website). The confusion starts when I realise that for both events the function would be the same (changing the src of that HTML img element) yet I want it to have a different effect:
    • on the event of a user click change it for that user only.
    • on an outside event that doesn't involve a specific user, change it for all the users to see the same image. How does this work? what is the thing that makes the difference between a HTML change that only affects the users locally (on their actions) and a change that has a global effect (to all the users).

UPDATE !!!

I should have been more specific with what I don't know. I'm familiar with AJAX request and I already have the backend sorted.

In the frontend script I have an event listener for the event from the backend, and all my questions are actually about 'what and how to do it' after the event listener is triggered.

Now, what I want to do when this happens is to make some changes, the main one being to change that image IMG1 to IMG2 for all the users (as it would be a dynamic update to the website) but also:

I need that change to be permanent, so in a case of users reloading the page or new users coming in, they all should still see IMG2. (And the only time the image would change would be when the event listener on the frontend script will trigger again on the same backend event to change the image again (to IMG3) for example. And yes, in this example there is NO 'on click' request for the users to change the image, so ignore my example previous to the update.

Now to address your answers, I checked the web sockets stuff and it seems to be doing what I need if I run that 'on event' change of image to all sockets. Which only leaves me with 2 questions now:

1) Will this change that occurs on all sockets to change the image be permanent, so in a case of users reloading the page or new users coming in, they will all see the new image (IMG2) as a permanent change to the webpage ?

2) Regarding these type of permanent changes, isn't reactJs a way of doing such changes dynamically? What would actually happen if on that event listener (for the backend event) I simply ignore all the web sockets stuff and run the same code of changing the src of the image ?

2.5) Because from how I see it, that event in the backend fires without any specific user input, thus is not linked with any user. So if I simply run the code on that event without websockets It should either do absolutely nothing (so no change for anyone) OR do the change for all the users (acting simply as a dynamic update to the webpage). How does this work?

I'm looking forward for your answers, and thank you all in advance!!!

Zinca13
  • 23
  • 3
  • Additionally if you would like the “100th anniversary” image to appear for every user immediatelly (not just after the first reload) you need to use websocket. – gazdagergo Jul 29 '18 at 17:56

2 Answers2

0

The difference may be between a front end, running in the browser, or the mobile app, of each user, which is local, and the back end, where you can share data between all users.

This can be implemented by, for example, firebase. Here is an example: Firebase - Multiple users simultaneously updating same object using its old value

This does not mean, obviously, that back end data is always shared... In many cases each user accesses his own copy of back end data that is stored in a database.

Yossi
  • 5,577
  • 7
  • 41
  • 76
0

The click event needs to be handled by an AJAX request, sending a message to the server and the server will handle that and respond. Upon the response, the first type of event is executed for the user.

On server-side you will need to have an event queue somewhere, maybe in the database. If you are using WebSockets, then you will have to execute the second type of event for all users if the request is met via WebSocket channels. If you are not using WebSockets, you will need to do polling from the browser. Anyway, you will need a counter on the server-side to be able to determine when the second type of event is met.

EDIT

Yes, WebSockets are the way to go unless there is a strong reason not to do so, like a boss saying he or she does not want the server to use WebSockets. With WebSockets you have a live channel between the server and the client browsers. You can use this channel to send the URL change to the client. On the other hand, the client will have to handle the change with Javascript, gathering the tags where the src is to be changed and change them. If you happen to have a class of changable for all such tags, then executing the change can be done with a function like this:

function changeSources(newSrc) {
    var items = document.getElementsByClassName("changable");
    for (var index = 0; index < items.length; index++)
        items[index].src = newSrc;
}

However, this change will be effectuated only for the loaded page which was initially loaded and upon new loads, this, by itself will not use the new src. So you will have to solve that problem as well. A neat way to do it is to store the new src on the server before you send it out to the client via WebSocket and use this stored src as the src of those tags when the client requests for the HTML. So, your problem has two parts, the first is changing the src on already loaded pages and the second is making the change permanent.

ReactJS is a Framework. At this point we need to define the technical background, since ReactJS will use a possible solution from these.

WebSocket

https://www.npmjs.com/package/react-websocket

This is a WebSocket implementation. The best technical background here is to use WebSockets unless there is a very good reason not to do so.

Server notification system

https://www.npmjs.com/package/react-notifications

Server notification systems in general are one-way ticket roads. The server may send a notification, but the client has no such possibility.

Polling

The browser may periodically send HTTP requests to the server and this way it can receive the src change response. This is a good solution if WebSockets and server notification systems are not an option.

Forever frame

You can use an invisible iframe to be loaded forever, which will provide you with the possibility of sending real-time messages from the server to the client, but this is very hacky.

Lajos Arpad
  • 64,414
  • 37
  • 100
  • 175
  • Wow, great response! This is a personal project so I can use whatever does the job, so I'll stick to using Websockets. From what I've seen on how to do the websockets stuff I deal with 2 main scripts: (1-the front end one) and (2-the server/websocket stuff), the flow being something like: (1 > 2 > 1) and it's all clear to me. However, this **store the new src on the server ... and use this stored src as the src of those tags when the client requests for the HTML** is where you could be more specific as it's a bit confusing. Only if you are not bothered, as you helped me a lot already, thanks! – Zinca13 Aug 01 '18 at 19:31
  • @Zinca13 The optimal way of storing this information on your server depends on your exact situation. A database table holding data related to images, like click number and stuff like that seems to be intuitive. In that table you can signify somehow which image is to be shown. For example a timestamp which is inserted and/or updated as you like. – Lajos Arpad Aug 02 '18 at 19:11