v8.1.0
When you have a view open and haven’t saved changes and the connection is lost to the Ignition gateway, all changes are lost when the gateway connection is restored, as the View reconnects and reloads itself… I’ve been burnt by other applications so saving is usually one of my strong qualities, but with lots of ad-hoc work interrupting me at the moment, sometimes I forget… I’ve lost a bit of work lately due to this
I’ve experienced similar behavior, particularly when I try to save session parameters, I’ve often had to restart designer for the changes to take. Also on v8.1.0
i lost 2hrs of elective study from inductiveuniversity due to not saving
i will keep in my my memory forever 
Under security->general you can now use auth tokens for authentication in designer.
This will help you with this issue
Switch from classical to Identity Provider.
NB. make sure your designer permissions settings are correct after switching.
Has anyone heard any updates or more information on this subject? We just had our development server reboot, which caused some unsaved changes to views to be lost.
I was always under the assumption that changes to views were stored and staged on the local machine that the designer is running on and losing connection to the gateway wouldn't get rid of any unsaved progress as long as you don't close down the client before the gateway reconnects. Guess I was wrong on that.
Perspective only runs on the gateway, so the designer has to send everything to the gateway for testing.
Your assumption is actually true for Vision.
Is this actually a constraint that would keep that functionality from working? Couldn't the project resources that we edit in the designer be brought and temporarily stored/cached locally but continue to be sent to the gateway for testing?
Guess I am also ignorant of some of the perspective stuff because I thought the perspective sessions were running/rendered locally. Admittedly a gap in my knowledge. I had thought what was actually happening in the background was the gateway was sending resources to browsers and the browsers handled the session with some socket communication dealing with actual data connections. Something for me to read up on I guess.
I don't know the details, sorry. Someone with insider knowledge would have to chime in.
No. The actual mechanism running behind all Perspective sessions (bindings, expressions, property referencing, scripting, keeping the component states in sync between the frontend and backend, etc) only exists on the gateway scope. Copying it into the designer scope would be technically possible (an absolute nightmare to untangle at this point in time, but possible) - but my educated guess is the reason it wasn't originally designed that way (and won't be changed to work that way in the foreseeable future) is because there's already a difference between the way the designer works and the way a 'real' session works, and doing things that way would significantly magnify those differences. I could go into more detail here, but basically it would make testing and developing in Perspective, for us and for you twice as complicated, because there would be many more subtle and not so subtle differences between the way a designer session works vs a "real" session.
All that said, the core issue you're describing (network connectivity blips and the view I had open in the designer refreshes) is also not necessarily just something you have to live with. Another educated guess (I know a lot about Perspective internals, but I wasn't part of the initial implementation nor am I an active contributor at the moment) is that refreshing the local browser instance is basically just the simplest way to "get out of jail free". If we didn't refresh, you could get into weird inconsistent states, where the loaded frontend state you had (before the network refresh) disagrees with the loaded backend state (always 'fresh' from the gateway), which would lead to weird and confusing errors.
In other words - I could see us, at some point, either coming up with a way to reconcile those states after a connectivity loss or at least allow you to export things before we trigger that refresh on your behalf. Couldn't tell you when that might happen, but I wouldn't call it impossible or even unreasonable to ask for. I would say a useful next step would be an ideas portal post or a direct contact to our support department - describe what you're experiencing as a bug (I think it's reasonable to call it that, as an end user) and we'll triage it accordingly.
Doesn’t this functionality already exist in part. As there is a way to reconcile differences between your designer and the gateway in the event that a peer saves the project that you’re working on to the gateway.
I understand it’s a bit different, but should the designer keep a local copy as you described earlier, then the ability to reconcile differences between your project and the gateway already exists.
I’m sure there is some technical debt that I’m unaware of in storing perspective view data locally, but it seems like half the jobs already done.
Right, but the part that holds the actual Perspective view configuration/definition is the browser session, and collecting the saved config from the browser is a relatively heavyweight (and fragile) operation; hence all the 'view config is undefined errors.
So maybe the answer is some opt-in mechanism in the designer/project properties, or we just pop up a confirmation box right before we reload your pages that says "hey, you might have unsaved work, we can try to retrieve it, but that might also fail" and then reload the page, reapply the edit, and let you resolve conflicts if needed.
Again - not insurmountable, but also not my product area.
