[Editor] Add code folding state to brew metadata

[G-Ambatte]

Your idea:

As per the comments on #2392, there is potentially value in storing the code folding state of the brew, allowing these folds to persist through a closing/reopening or even just refreshing the page.

I would expect that this data would be stored in the Metadata; as it's Homebrewery specific data and not required to rebuild the brew, it would live in the stub, rather than in the Google brew data.

From editor.jsx, the code to fold the brew source should be as follows (where X is the line to fold at):

this.refs.codeEditor.codeMirror.foldCode({ line: X, ch: 0 });

Please confirm:

• [X] I have searched the Issues tracker for any duplicate requests and found none.

[calculuschild]

I think this is fine. Makes me wonder if there's some other UI/UX settings that should be saved per-brew. Cursor position (and auto-scroll to matching brewRenderer position)?

[5e-Cleric]

Confused dev here, is this issue proposing a call to the db for every fold/unfold interaction? cause that would be problematic.

Or is it proposing to log the current state of folding in a cookie or somewhere else and log that to the db every few minutes, or even when the brew is saved?

[G-Ambatte]

I would imagine at least on close, probably on save as well. Just write the current document folding state into the metadata so it can be saved with everything else, and add a function to apply it on loading a document. This should result in no additional server calls, just a slight modification of the ones already being made.

[ericscheid]

Hmm .. on saving would mean there is only one state for a given brew, which would be problematic if there are multiple authors.

How about saving the state in LocalStorage in the browser, keyed to the brewid? This way there is no roundtrip delay, no server hit, no db hit, and is multi-author friendly. The only thing it isn't is be portable between devices by that author.

[G-Ambatte]

Multiple authors is an interesting case to consider... If we store folding information for an author, and a different author modifies the document, then the folding information is out of date - depending on the edits, the document may no longer contain the lines that need to be folded, or new lines may exist in the folded region.

I'm not certain that I have an answer for it just yet. I suspect that I would lean towards storing the information in the document rather than the browser,

[5e-Cleric]

the document may no longer contain the lines that need to be folded, or new lines may exist in the folded region.

This is very important, i think keeping the same folding state for all authors is not that bad, considering the issues we would face otherwise.

[G-Ambatte]

I spent some time poking at this yesterday; the getAllMarks() function returns the fold marks, but as best I have been able to determine so far, these marks do not contain identifying information about the lines or ranges that they have come from.

At this stage, I suspect that the next approach will be to build a collapsedFoldMarks list by stepping through each line in the document, and identifying the unique fold marks on each one. Such a collapsedFoldMarks list would be something like:

[
  { from: 0, to: 5 },
  { from: 12, to: 18 }
]

During the opening of a document, this list is processed to automatically close the fold ranges from the list. At this stage, I haven't conclusively identified a method to cause the fold to close.