Unify new and edit pages

[G-Ambatte]

Draft PR for the unification of the newPage and editPage files. At this point, the code appears to be completely functional and all newPage files have been removed.

CHECKLIST:

• /new saves to and loads from local storage automatically
• clicking save on /new redirects to /edit and wipes local storage
• importing from a Share ID via /new/:id works
• saving on /edit works locally
• transfer to/from Google Drive works
• other functionality that I've currently forgotten about

Notes:
Transfer to/from Google Drive: should work, but testing is required.

[calculuschild]

I know this is a lot, so please ask if you disagree with any of it or have questions; this is super awesome work so far and I think it's getting close.

[calculuschild]

This is requiring that the brew must have both empty text and style, and also that both localStorages must be full. If a user only adds text to the localstorage but not the style, this will not load anything from localstorage.

Suggested change

	if((!brew.text && localStorage.getItem(BREWKEY)) && (!brew.style && localStorage.getItem(STYLEKEY))){
	if(!brew.text || !brew.style){

This way when a new page is loaded, if the brew has any empty tab it will check the localstorage.

[calculuschild]

Can this all be moved to save()?

trySave() shouldn't have any actual save logic. It's only meant to insert a delay between saves.

[G-Ambatte]

It can be moved; save() is called by the Save button click handler but also this automatic save function, so those two states will need to be disambiguated.

[calculuschild]

trySave() should trigger automatically when a user types (or edits metadata, or changes google Drive status) and we detect that the content has changed. This just sets a timer for SAVE_TIMEOUT miliseconds and ignores any other save requests until that time is up, at which point it calls save(). If the user undoes their change before that happens, the save will not trigger if I remember right.

We can keep the save button calling save() directly since I don't think users want to click and nothing happens for 3 seconds, but otherwise everything else should use trySave() so every little edit doesn't send data to the server. Saving to localStorage can also happen in save() since I don't think there's any real benefit to rewriting the localStorage with every single keystroke.

[G-Ambatte]

Yes, absolutely; what I meant is that because save() is called by clicking the SAVE button, it causes the Brew to be saved to the appropriate HB/Google storage and redirects to the /edit page, whereas this automatic saving from /new only saves to localStorage. So if we put it in the save(), we'll need a way to identify that this should be saved to localStorage, not MongoDB or Google Drive.

We could also create a new function, e.g. saveLocal(), and drop the three lines of code into that.

[G-Ambatte]

I'm now wondering about a this.saveLocation variable with possible values of Homebrewery, GoogleDrive, BrowserCache, which direct the save() logic. It would be more extensible than just using the single this.saveGoogle boolean.

Probably outside the scope of this PR, though. Maybe in a refactor PR.

[calculuschild]

Ah I understand now. Yes that sounds like a good approach. I don't mind if you want to add that in so you can move the local storage saving to the save function.

[calculuschild]

Although you are right it might not be that straightforward. If we set saveLocation to local storage, we'd have to have another check to switch back to googleDrive when the user manually clicks save on the new page.

Could also be a parameter we pass into the save function.

[calculuschild]

Maybe if saving comes from TrySave, pass a "autosave" parameter to the Save function and then we can handle it in there depending if it's true or false.

[calculuschild]

@G-Ambatte What stage is this at now? I know this is a pretty huge task, but unfortunately that makes it easy to fall out of date with the current master branch. Would it be better to break this up into a series of smaller PRs focused on refactoring just one section or function at a time? I think it might be easier to manage (and for me to review).

For instance, take the saving function (or something smaller) that we need to kind of meld two versions together. Update that function on both /new and /edit with the only difference being a flag at the top (if page == "edit") that determines how the function runs. Start copying over bits from /new that need to be in the combined version over to /edit, and vice-versa, even if they aren't going to be used on those pages right now. And slowly make the two pages closer and closer to identical until we can just delete one, and it will all be in sync with the latest and greatest on the Master.

[G-Ambatte]

Superceded by #1799.

[calculuschild]

Superseded by #1801