1

I'm building a SPA with React as the front end. It basically consists of a dashboard-like page with 3 separate (but semi-connected) components. The components are:

  1. a messages/notifications area - user interaction consists of clicking a button to "dismiss" any of the messages
  2. an area with form inputs, buttons and lots of user interaction
  3. a datagrid with inline editing capabilities

Crude Wireframe: enter image description here

The content of all 3 is derived from a combination of:

  • user interaction/input on the page
  • info fetched from the backend API.

2-way binding is in place, so the UI state as it pertains to the former is already taken care of. It's the latter I'm writing this post about.

Other users using the app at the same time may cause changes to the backend that need to be reflected as immediately as possible in all 3 components in order to create the experience of them being "live". I am considering 2 approaches:

  1. query the backend on a set interval to check for updates for all components
  2. query the backend for changes to the active component when it becomes active/focused (i.e. the one the user has just clicked inside of)

And I guess there's a third option of doing both.

I'm conflicted regarding #2.... will a split second of latency in the first click on the component EVERY TIME be frustrating for the user? or is it more frustrating to be working on something within the component and be interrupted for that split second while state is updated?

  • How time sensitive is the application? And how often do the information need to be updated/refreshed? – Michael Lai Feb 11 at 1:32
0

There's a lot of context that could change this but in the situation you describe updating on intervals is far better.

Seeing things update live is a positive user experience. Having page components updating themselves is good. Stopping or interrupting users when they're trying to do something is bad.

Use REST architecture. Have the backend generate xml of the current data. The components simply load the xml instead of querying the backend. Optimize the xmls down to nothing but updates and you can probably update often.

  • My backend is a RESTful API... currently returning JSON. The component makes a GET request to the specified route and updates the application state based on the response received. Once the state object is updated, the UI (and its elements) within that component update/adjust accordingly. Are you referring to a different workflow? I haven't heard of XML being used since the earlier AJAX days - have we come full circle here? – Daveh0 Feb 11 at 15:07
  • You usually don't use GETs in REST, you just load static text files. The current data or updates should be written to static JSON files when the data is updated. The client apps can load the static files on interval. The client should only use POSTs to update the data. If the POST is an update to the data, the JSON files get updated. JSON is like XML optimied for javascript. If you really need to optimize, use comma delimited text and parse it yourself. Both JSON and XML are huge wastes of size and their parsers are slow. – moot Feb 12 at 0:23
  • I definitely agree that XML is extremely inefficient 4 return & display of async data. I didn't think JSON was anywhere near as bad, but i've got to say that RESTful APIs use endpoints for a variety of request methods, GET included. I agree that the static text file method definitely sounds faster for the client when feasible, but I guess all this is straying from the point of the original question. In my case, having the client retrieve updates (through whatever method) on an interval is probably doable. I guess i'll have to get a bit more info on expected update size and frequency. – Daveh0 Feb 12 at 4:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.