This may have broken the existing use-case (the "not" workflows)
Preview file, edit file, click settings (triggers notifyDirtyFile), click saves, click 'Confirm'. This opens the task-window that shows the upload.
Some very big design issues with the current implementation is that double-clicking on another file in the file tree, that is not a text file, is how this should be handled. Currently, the Vfs-implementation will fetch the file (if small enough) and check the contents and attempt to text-decode. If not considered text, it will prompt the user to navigate to the Preview component for the different file-type. This is very not good, no, not at all.
One solution could be that we keep the lhs (the file-tree explorer) and the rhs (currently the editor window) will be able to be switched between editor and rendering of content using the built-in browser tags, which is probably the best approach.
One thing that we need to handle is cases like markdown. Preview is one thing the user might want, but editing it is another thing they also might want. How do you decide which to do initially?
Also, the file-tree next to the editor shows the immediate parent folder of initial editing instead of the root. Root could be used instead, but at that point, we break the promise of only allowing one way of doing things, and two full separate file-traversal systems would not comply.
This technically works.
This may have broken the existing use-case (the "not" workflows)
Preview file, edit file, click settings (triggers
notifyDirtyFile), click saves, click 'Confirm'. This opens the task-window that shows the upload.Some very big design issues with the current implementation is that double-clicking on another file in the file tree, that is not a text file, is how this should be handled. Currently, the Vfs-implementation will fetch the file (if small enough) and check the contents and attempt to text-decode. If not considered text, it will prompt the user to navigate to the
Previewcomponent for the different file-type. This is very not good, no, not at all.One solution could be that we keep the lhs (the file-tree explorer) and the rhs (currently the editor window) will be able to be switched between editor and rendering of content using the built-in browser tags, which is probably the best approach.
One thing that we need to handle is cases like markdown. Preview is one thing the user might want, but editing it is another thing they also might want. How do you decide which to do initially?
Also, the file-tree next to the editor shows the immediate parent folder of initial editing instead of the root. Root could be used instead, but at that point, we break the promise of only allowing one way of doing things, and two full separate file-traversal systems would not comply.