Auto-saving is cool - as long as you never make mistakes!

@nampdn Not sure where you got that impression from, our response to daniel’s suggestion was “yes, this is already in our todo list :slight_smile: 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. :frowning:

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.

Sorry about that, maphew.

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.

1 Like

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!

Alright,

there is a simple hack you can use to disable auto-rebuilding :slight_smile: 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:

{
  "install": {
    "include": [
      "^package\\.json$",
      "^\\.env$"
    ]
  },
  "restart": {
    "include": [
      "^.trigger-rebuild$"
    ]
  },
  "throttle": 100
}

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 :slight_smile:

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.

6 Likes

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 :wink:

2 Likes

Thanks for your feedback danroot,

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.

Thanks again! Happy coding.

1 Like

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.

1 Like

Hi scunliffe,

we know, and this is exactly the problem that we will try to address with branching :slight_smile:

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.

4 Likes

Done this with gomix quite a few times myself

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.

1 Like

OK, I have a partial solution.

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

The project is here.on glitch

It’s also on github, here. So you can clone the remix the project on glitch and fork the project on github and export your changes and send me a PR.

You can also join the project here.

The README.md gives all the details

Thanks for the offer Tim, but I didn’t see it in time. I took a 5 month holiday from Gomix/Glitch instead.

I had a similar lost content event today, but nowhere near as serious, only losing 2 lines this time. It’s related to network connectivity. The safe thing to to do is to completely stop any kind of typing when there is “Reconnecting…” message at top right, except to copy everything from the current window to somewhere else for safe keeping.

I get the reconnecting message several times an hour, sometimes several times in a few minutes. Other browser windows do not show a connection problem, but their behaviour is quite different. Almost all passive consumption (reading, searching, etc.). My suspicion is that my upload link is too slow or has high latency.

1 Like

I accidentally made something popular, and I’d like to develop it further, but I’m afraid that it’ll break for users as I’m hacking on new stuff. So I guess I’d like to be able to brach the project, hack around with it, then merge it back into the original when I’m happy.

4 Likes

yup the flow we’re using to develop the community site without breaking it is to remix your project, make the changes you need to make, then export your remix to a github repo, then import that repo into your existing project.

We’ll eventually have something better, but it’ll take us some time to get there

5 Likes

I know that I’m “late” in the discussion, but I want to bring out a separate point that might be very important.

I don’t make express apps. I actually make discord bots. I am constantly on the prowl for interesting free VPS that the people that I teach bot making to (more often then not, young teenagers with little or no money) could use to host their small bot projects.

Most VPS’s are either too complex to use (see: heroku) or can’t save data locally (see: heroku).

Now beyond the fact that Glitch can save data which is great (JSON, SQLite, etc), there’s one tiny bit of an issue that’s covered here but is actually a really hard barrier to using Glitch: Discord Bots are limited to 1000 “logins” every day. If a bot logs in more than 1000 times, it’s considered to be “broken” (or glitchy, lol) and its token is reset so that it stops spamming the API.

Now here’s the problem: If your editor constantly auto-saves basically every single character I write it means every single character causes a reload which then causes a login, which obviously is going to be causing these serious API-spamming issues.

And this affects any sort of code that, on load, does any sort of query on a rate-limited system.

And - sorry if I ramble on a bit here - some solutions here include “push with git”. Well, I’m sorry but your front page clearly shows you targetting people even younger than my base clientele of 13 year olds (I think it would probably attract my 6 year old daughter, visually) but you want people to use a git push system… There’s quite the schism here.

1 Like

Using a watch.json file in your project to override the default behaviour for specific files or file types would seem to workaround this issue: https://glitch.com/faq#restart

Understandable that watch.json is a workaround for it saving every word I type and restarting the app. It does not however sound like a proper solution, since then you are ensured that whatever “delay” you put in the watch.json is however long you’re going to have to wait for your app to restart when you are ready to push the changes.

This issue’s been going on since April 2016 and no one’s cared enough to make a “Disable auto-save” checkmark that stops the front-end from saving automatically?

It’s not a lack of care, it’s a product decision to help avoid unnecessary complexity for the majority of use-cases. For the most part it’s fine, but there are edge cases that make it difficult and we’re always considering the best approach as new constructive feedback is provided.

1 Like