knowing when a firepad is synced

[Mika Genic]

I want to show an indicator to the user if his document is synced (saved) or not - a green/red icon or something like that

Is there any call I can use for that ?

Thanks!

[Beni Cherniavsky-Paskin]

As docs say:

 'synced' event is fired when your local client edits the document and when those edits have been successfully written to Firebase.

firepad.on('synced', function(isSynced) {
  // isSynced will be false immediately after the user edits the pad,
  // and true when their edit has been saved to Firebase.
});

You might want to debounce to reduce flicker after every keypress.

On https://www.mathdown.net I'm immediately changing a message & CSS class:

https://github.com/cben/mathdown/blob/87c7f0b6cb28b4a3b6cf5a55aec12c5bf41d3d28/mathdown.js#L267-L274

but applying some simple CSS transitions:

https://github.com/cben/mathdown/blob/87c7f0b6cb28b4a3b6cf5a55aec12c5bf41d3d28/mathdown.css#L23-L47

creating the effect that during typing a yellow "Unsaved!" message slowly fades in, then (if you're online) turns into "saved" and quickly fades out.

I also have unfinished work [https://github.com/cben/mathdown/issues/56] that listens to Firebase's ".info/connected" status,

and even periodically independently tests the saved text by reconstructing with a headless firepad,

trying to show more informative statuses, e.g. yellow "Unsaved!" vs orange ""Offline — Unsaved changes!" vs "Online but unsaved — BUG?"

[https://github.com/cben/mathdown/blob/8d031b746c993ea7baa64febe11f50aadaea20b4/mathdown.js#L232-L287].

It's unfinished because of false alarms — during typing the headless-reconstructed text may repeatedly differ from the current text, and I haven't gotten around to constraining the reconstruction check to stable periods, debouncing and unit testing the logic...

But ignoring my paranoid headless check, I think only adding ".info/connected" to your status would be easy.

[The reason I wanted the paranoid check is not distruct of firepad as distruct of my own code interacting with it, which has caused at least one silently-not-saving bug.]

--
You received this message because you are subscribed to the Google Groups "Firepad" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firepad-io+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firepad-io/d54f48bc-244c-467e-ada2-ad049672df38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mika Genic]

Thx alot Bni!

Can you explain the need for reconstructing with a headless firepad on top of checking info/connected ?

Also just thinking, perhaps your false alarms can be fixed by setting a timeout - so that an info/connect status will be displayed only if it is still current after a few seconds etc ?

[Beni Cherniavsky-Paskin]

2016-01-25 0:34 GMT+02:00 Mika Genic <mika...@gmail.com>: 

Can you explain the need for reconstructing with a headless firepad on top of checking info/connected ?

I mostly wanted to show you just info/connected, I just had them together on that WIP branch. 

(Actually headless is the one I wanted, and I added info/connected on top of that to distinguish a deep problem from user simply being offline.)

Most people probably don't need the headless thing; I do because I write buggy code :-)

I've had a bug where my (unrelated) CodeMirror event handlers somethimes threw exceptions (I've since learnt to wrap them all in catch-all),

which caused Firepad to not get the events, sometimes leading to situation when Firepad fails to save anything - with no indication to the user!

Oh, and I've had it for many months :-((.  That terrified me (good thing I had near-zero users).

I've reproduced the 1st problem and confirmed that 'synced' could be true in this situation.

In another instance, I accidentally upgraded to a known incompatible firepad/CM combination, and it also didn't save.  At all.  That one I caught quickly.

(Haven't checked what would 'synced' indicate there.)

So I don't trust myself, and can't imagine an exhaustive way to test it, but I decided "never again".

Whatever unexpected reason might come for not actually saving, I want users to get a visible indication.

Also just thinking, perhaps your false alarms can be fixed by setting a timeout - so that an info/connect status will be displayed only if it is still current after a few seconds etc ?

Yes, a bit trickier than that.  I'm debugging with headless reconstruction every second, but I'll want to limit it to 1–2 per minute.

During active editing (local and/or remote), OT means that local text might *legitimately* never equal remote text.

The check is only meaningful when everything settles down.