Be careful not to completely rely on navigator.onLine for this as your next request could be the first to fail, so you need to deal with submission errors and timeouts too (or safer: always put the data in local storage and remove once you have confirmation of a successful save).
The article seems good overall though, I can forgive leaving out some of the nitty-gritty like this to keep the main points clear.
A rough way to do this would be to add a hidden UUID value in the form data that is generated once up front and used by both the client and the server to ensure that the result of the first successful request can be cached and re-returned.
You really don't. You can, as mentioned above, have a hidden UUID field in the form that's used serverside to deduplicate submissions within a given timeframe.
(Or more likely and more on-topic, for the offline-friendly form if the application gets the error first, the application could be smart enough to try again...)
The UUID doesn't guarantee anything other than capability to prevent duplicate records from duplicate submissions. Something else has to be responsible to make sure the submission is not abandoned without user input, unless a 200 or other successful status is received.
Take a look at how Stripe guarantees at-most-once execution: https://stripe.com/blog/idempotency.