Instead of auto saving immediately on every keystroke, what if each keystroke started or reset a timer for an auto save that happens after a short time? Only after you stopped typing for a period of time would the auto-save complete.
One way to represent this in the UI would be…
UI state with auto-save enabled:
Circular countdown graph moves around buttons that represent “save / pause auto-save” during a save countdown that change to “saved / undo” when everything is saved.
UI state with auto-save paused:
Circular countdown graph motion disabled, the buttons would represent “save / start auto-save” when unsaved changes exist or “saved / undo” when everything is saved.
yes, this is already in our todo list It didn’t make it for the release date, but will be online anytime soon.
Thanks for the suggestion on the visual feedback! I think that initially we will just use very short delays so the feedback shouldn’t be needed. In the future we will consider using your approach! I really like it!
Warning, DO NOT EDIT YOUR APP ON MULTIPLE DEVICES!
In testing the rendering on my iPhone, I figured I might try to see how the editing works there… spoiler… it works, but it is a bit painful (not so much the editor, but just the phone/keyboard sucks for coding).
Anyway I pushed that aside and went back to my laptop, code, code, code… I made a bunch of worthy progress and went back to my phone to look at it… but because I still had the editor open… in an older state of the code… the auto save kicked in and I lost all my work… not thinking I went back to my laptop, thinking that the phone issue was a caching issue and I hard reloaded my laptop to “pull the true source”… which was now the server version… from my phone, from ages earlier.
I hate to be a squeaky wheel about this, but I’m finding this auto-save to be the most annoying “feature” of Gomix right now. Every time I partially type some code it is trying to re-deploy and throwing errors right left and center… constantly hitting external APIs for content I don’t need to fetch until my next actual save/test.
On a more minor note, with a touchpad as a pointer it is very easy to accidentally select text when scrolling. I ended up deleting a bunch of code accidentally when I scrolled… selected by mistake… then when I went to hit Esc I hit Backtick instead, replacing my code with “`”
I hereby strongly re-request the ability to turn it off. I do not want it turned on, ever.
I’m sorry that happened to you, scunliffe. Just FYI, your mental model of how autosave works isn’t quite right. When two editors are connected, they aren’t saving and overwriting each other’s changes. They are editing the same document, like Google Docs. In your case, it sounds like something went wrong with that, but in general having two editors at the same time shouldn’t be dangerous.
When you were editing the code on the laptop, were you viewing the changes to the site itself, or just editing the code? If so, then we should have a backup of the good code. What project was it, and what time did you lose the changes, roughly?
If you weren’t trying the site while editing, it’s possible that the changes made on the laptop were never saved to the server. This is a little more likely, I think, since they didn’t show up on the phone. If that’s the case, I’m sorry to say, there won’t be any way for us to get them back for you.
We’re putting the infrastructure in place this week to allow you to go back in time in the project, so if this kind of thing happens in the future, it will be much easier to roll back to a working version.
additional note: It sounds like scunliffe hit a (extremely serious) UI bug that may be related to the editor allowing text entry when offline. I’ll make fixing this issue a priority.
(the ideal way to fix this is with local caching of diffs when offline and merging them properly when connected, but we’re a bit far from doing that in the short term sadly)
In this case, I don’t need the backup now as I’ve re-coded everything I lost. I don’t know the specifics of how your collaborative editing works but I’d like to point out that my scenario has some specific differences from a collaborative scenario.
I was editing from 2 locations with the same user.
I was interacting with Safari on an iPhone… which means that it very likely may have reloaded/re-posted when coming out of sleep/hybernation… because, well, iOS Safari is bonkers and you can’t turn off the unnecessary reload
That all said, regardless of how the auto-save works (or doesn’t)… conceptually I can’t stress enough how much I don’t want any part of it. I want an actual save option, that works 100% of the time because it is an IMPLICIT action, not a passive, NON-IMPLICIT action. I will only want to save when I click save, or when I press CTRL+S.
A version history will be great too, but it needs to be per file, and this just seems like a band-aid for the real issue.
There’s just SO MANY scenarios where auto-save can go wrong (only a few have been noted in this thread, none with solutions) that it just isn’t worth the risk of trying to duct tape it to try and make it work.
@nampdn Not sure where you got that impression from, our response to daniel’s suggestion was “yes, this is already in our todo list It didn’t make it for the release date, but will be online anytime soon.”
The same thing just happened to me, only I don’t know what key combination triggered the loss.
I was in the middle of typing and all of the sudden the last two characters typed were in a different file (readme.md, where I had been working in server.py). There was a “we seem to be having trouble communicating with the server. Perhaps try refreshing” message from top right.
I switched back to the file I was working in, and the entire thing was blank! Ctrl-Z had zero effect. I reloaded the page from browser (Ctrl-R) and the file is still empty.
Auto-save is cool, but auto-reload without undo is horrible.
There’s another issue with auto-save and auto-deploy when you accidentally create an endless loop.
I had a bunch of code that I wrapped in a for loop… ‘][’ is the cursor:
“for(][){”
I only got this much of my for loop typed in my for loop structure… ‘][’ is the cursor:
“for(var i=0;i<list.length;][){”
because this created an endless loop (it is missing the “i++” iterator), both the editor and the auto-synced view choked. In the end it did come back, but any attempt to type failed because it was trying to execute unfinished code.
I really can’t stress enough how much I am despising the auto-save. Please add the ability to turn it off soon. This will only get worse when dealing with versioning and dev code vs. deployed code.
Your code is regularly backed up while you’re working on it, so we can get that file back for you, and try to figure out what went wrong, if you let us know the project details.
This is similar to the issue I mentioned way up top. I still think auto-deploying incomplete code is really dangerous. Imagine you were typing:
executeSQL("DELETE FROM [user] WHERE user_key = @blah")
If you completed the quotes/brackets before typing the command, this would potentially wipe out the whole table (I know this is a contrived example, but it illustrates that incomplete code can be dangerous pretty well).
I don’t know if anything has changed with this (it’s been a while since I used Gomix; I was just coming to see how things had changed) so if there’s already an option for this, great! If not, I really think it needs one!
there is a simple hack you can use to disable auto-rebuilding it won’t disable auto-saving, but it will make sure that changes to the code don’t trigger a restart.
Create a file named .trigger-rebuild and a watch.json file and put this code in it:
The only change that will trigger a rebuild is a change to a file named .trigger-rebuild. Changes to .env and package.json will still trigger a reinstall + rebuild. If you don’t like that, you can remove those from the file. Beware: changes to watch.json will always trigger a rebuild.
Caveat: this only works during the editing session. If you close the editor and stay out of the project for long enough (around 10 minutes) the project will be stopped and then rebuilt and restarted the next time it is visited.
I acknowledge it is an hack, but I think it delivers what you want – at least until we implement proper branching and rollbacks
UPDATE: since it is a bit cumbersome to always go to that .trigger-rebuild file and edit it to trigger a rebuild, you can also put this bookmarklet in your bookmark bar, and name it “Rebuild!”:
javascript:(function() { var currFile = application.selectedFile(); var triggerFile = application.files().filter(function (file) { return file.path() === ".trigger-rebuild"; })[0]; if (!triggerFile) { alert("Please create a file named '.trigger-rebuild'."); return; } application.writeToFile(triggerFile, `restart-${Date.now()}`); })()
Make sure you have a file named .trigger-rebuild in your project, otherwise this script won’t work.
To throw in my two cents. I really like both auto-save and auto-deploy for the most part, but do see how both can cause issues in some scenarios. In my usage, the main issue is that I can break the app until I finish typing. For example, my bot stops responding until I finish figuring out some regex. The branching you mention would solve this.
That said, I am wondering if Git isn’t the better place for that. Let Glitch be good at coding and running, and Git be good at versioning and branching. In fact, it’s possible to do branching and versioning today using git import/export. Develop myapp-dev.glitch.com against a dev branch, and then when ready merge to the main branch and import into myapp-prod.glitch.com. Tighter integration (like CI so that merges to git get automatically deployed) could improve that. The argument against this is that it would be harder for users not as familiar with git, but maybe glitch can make it as drop-dead simple as they have the other things
this is exactly our direction. We’ll make use of git underneat, but we are trying to make it usable even for people that are not familiar with it. It’s a big task, and we are evaluating it very carefully. We want to deliver the full power of git for the pros, and a clean, fun and functional interface for the beginners.
However, we felt like a temporary solution was needed, as this is one of the most active threads in the forum. So I provided a simple hack to disable the auto-rebuild step.
I think there is still a huge disconnect here between what developers want and what this tool is providing.
In my local, normal dev environment(s) I have a watcher that watches a directory. When enabled (normal) it detects any new files, file deletions, and file saves… automatically triggering a (build*)/deploy to my SANDBOX environment (*depending on the code base type). This works insanely well because it only deploys files that are saved, and it only deploys to my SANDBOX, so nothing bad with the PRODUCTION version can happen as they are not connected. Pushing to Production is a separate step, done with much forethought due to how dependencies, DB scripts and versions work.
By removing the ability to do explicit saves, you’ve lost the ability to do explicit deploys. I don’t want any files to be deployed/compiled/? until I save a file… explicitly.
we know, and this is exactly the problem that we will try to address with branching
However, in the meantime (until the branching feature is shipped), the split between “production” and “sandbox” can easily be obtained by remixing. Say you have your app-production project, and you don’t want to live-modify it since it is… as you say, production. You can simply Remix it into a new project with a completely separate env, with different variables, you can hook a different database, and so on. You do your work there, and then you either export/import your work through github, or you rename the sandbox application to app-production.
UPDATE: as I already said, we know this workflow isn’t optimal as it doesn’t support branching. I am just saying that we are getting there. Consider the advantages of always having the same environment in both your production app and in the sandbox. Deploying becomes as easy as renaming a project.
UPDATE take 2: and consider we did exactly this for the revamped community site. Deploying it took 2 seconds (a rename), and worked like a charm. So it is a pattern that can already be used for “production grade” apps.
I would go further than this… Once an app is “live” (eg. not just a dev hacking around to test stuff out) I wouldn’t want anything deployed unless it is committed to source control.
That said, it’s possible this branching feature will provide exactly that; it’ll be interesting to see how it works once it’s available.
You can instantiate a git repository in a glitch project. So you can commit your work, make changes, and if you need to recover files, you can do that by
git checkout <file>
And you can do any other git command that you would like as well. So all the power of git and the power of glitch combined.
For example you can do:
git reset --hard HEAD and throw out all your changes since the last commit
It didn’t make it for the release date, but will be online anytime soon.
it won’t disable auto-saving, but it will make sure that changes to the code don’t trigger a restart.