I’m working on an app which incorporates an existing simple text editor and has hooks available for load and save operations.
I’m not sure how best to implement the storage for this (together with some kind of directory listing UI to let users retrieve previously saved files). I was thinking of using the storage api, but I see reports of it being buggy at the moment? Would it be feasible to simply use a ‘long text’ column on a board instead?
My minimum requirement is for individual users to be able to store and retrieve their own work. An added bonus would be to offer some form of sharing (subject to permissions) between users, so that they could collaborate on files.
And a final, extra bonus would then be integration with Google Drive, etc., but that would be the cherry on top.
I think the best thing to use for something like this would be our storage API, you can find more documentation on it here. For reference, this is what our whiteboard app uses as well.
If I understand correctly, though, that would preclude any collaboration on documents between users, the storage being private to each running instance of the app (even for the same user). Have I got that right?
The more I think about it, the more important the collaborative element seems to be. This is what I am working on - Monday Notebooks | Devpost
The ability to work on stuff privately would be a useful option in itself, and might also present the easiest starting point for an implementation, but ultimately…
I’d like to either duplicate the functionality of what you could call the ‘reference implementation’ - https://starboard.gg/ - where people can view each other’s work and clone their own copies to work on separately, or (perhaps even better) have truly shared documents with read/write access for a group of users.
I’ve been thinking about using a board with a files column as the repository for a set of documents with shared access for a group of users. The source and destination for ‘file’ upload and download (using the api) would be the users’ buffers in which they are editing, rather than actual external files. Would that be a viable approach?
I’ve been trying to get the storage API going and hit a weird problem.
Firstly, I’ve noticed that getItem(key) returns success, even if nothing has been written to the key yet. The data value is null, which I guess is what you have to check to test for this case. I presume that is the intended behaviour, it just caught be my surprise.
But the actual problem I am seeing is this -
I’ve confirmed that I can read and write a simple test string to/from a key, but when I try the larger string that represents the document I am saving, things go wrong. setItem() returns success, but getItem() gives the same outcome as when it’s a new key - success plus null value.
Can there be something about the content of the data that would cause it to fail in this way? My document contains code, a mix of CSS, HTML, javascript and other things. I tried a quick test, putting a code snippet in my simple test string example, and that still works, but I suppose there could be some very particular content that is causing the issue.
Evidently the problem is being caused by the multiline nature of the text. I can get the storage API to work if I replace all the carrioge return and linefeed characters in my text.
)
