Editing files in an app

[CMcConnell]

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.

Any thoughts?

[dsilva]

Hey @CMcConnell!

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.

Hope this helps!
-Daniel

[CMcConnell]

Thanks @dsilva,

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 - https://devpost.com/software/monday-notebooks

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?

Cheers,
Colin.

[CMcConnell]

@CMcConnell

Have I got that right?

Apologies. Looking more closely, I suspect I misunderstood the docs. Storage may well offer all the features I need.

I’ve seen example code for the storage API in the ‘Online Docs’ example app. I don’t think the whiteboard app source is available, is it?

[CMcConnell]

Hey @dsilva (and anyone else that can help )

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.

Here are some screenshots.

The working version with a simple test string-

The failure with the real string-

[…]

[CMcConnell]

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.