https://futureofcoding.org/ logo
Join Slack
Powered by
With <the conversation a few posts up> on my mind,...
# devlog-together
k
With the conversation a few posts up on my mind, here's an example single-file html with some support for annotation. Save it locally, swap out the text with some stuff to read, take notes on it as you read, save your notes locally. Thanks @Eli Mellen and @Tom Larkworthy in particular for the inspiration. Based on Cristóbal Sciutto's note example. Suggestions and feature ideas welcome.
t
Oh awesome! Welcome to the dark side. You can make the main text editable with "contenteditable="true"" on the TD, still saves!
contenteditable.mov
x
Very cool! This reminds me a lot of Webstrates, in praticular MyWebstrates based on Automerge.
k
That's the first example of this kind that I might actually use. Put differently, the use case is a good fit for the various technical trade-offs.
e
@Kartik Agaram something you may run into with the single-file HTML/JS approach to be aware of is that some devices won’t execute JS, or will only execute a subset of JS when reading the file directly from the file system as opposed to through a web server. This is a security measure to prevent folks from being able to easily embed and run malicious JS in all kinds of files (like PDFs 🫠)
t
it runs JS fine, its just file:// is considered its own origin so it can't do cross origin requests... e.g. fetching an external image. The security context is different than normal. There are work arounds because JS can manufacture in-memory URLs that are, by construction, in the same origin. But yeah, you are in heavy yak shaving territory at that point, and you need a good mental model of the security model to work around those limitations if you need to.
k
@Tom Larkworthy I ran with your suggestion to enable 
contenteditable
on the left side, and made some changes to the UI to go with that. Thanks a lot for the suggestion! It also validates now, with many thanks to @Eli Mellen. On my Android phone the core pieces all work, though there is some jank with the small screen size. The browser doesn't support saving the current page, but the save button works for me, though I had to iron out some issues so there may be more issues lurking for others. On SeaMonkey the save button doesn't work, but I can save using the browser's shortcut! So this is looking pretty cross-platform now!
t
yeah looking cool! Quite neat. I think the saving to a file workflow suits a forking history. Like maybe you have base note you open, modify and save. You Downloads soon filllup with similarly sounding filenames. For lopecode I use the DOM title for the base name, and then append the timestamp so its orders sanely in the filesystem. Probably I use too much precision in the timestamp now I look at it closely, lol. So I think you need a way to set the title of the note, and the timestamp trick to be naturally filename collision avoidant.
I am begging to think about what is history in this model. You could generate a UUID every save and include the prior version to form a linked list, but this seems kinda fragile if you lose a file in the middle. Or maybe keep a list of content hashes within the file so the history is inside the doc, but you might not necessary have hard copies of everything (but you can search your filesystem for those hashes perhaps), or maybe you really keep all the operations for full replayability (could be nasty size wise if we consider a file upload as a recorded operation), nice thing with keeping the operations is you can make a cool animation of the evolution over time. Should it just have git in there so we don't reinvent the the wheel and allow merging across different histories?
2 Views
Open in Slack
PreviousNext
Powered by