Hello, I am mainly curious if custom data can be attached to notes, or if there is support for saving custom local data for a plugin. Is this functionality feasible, or even allowed?
For example, attaching a custom time to a note so I can track it and calculate how many minutes I have been typing in that note in total.
This would be separate from the existing note edited time, and persistent across app instances.
Thank you!
Hi Andrew,
Thatās a good question.
Storing custom fields is interesting.
Itās technically possible to store fields like x-customField so the app can distinguish if they are custom fields.
For example:
import { actions } from "inkdrop"
const { dispatch } = inkdrop.store
dispatch(actions.editingNote.update({ 'x-customField': 'bar' }))
dispatch(actions.editor.change(true))
Note that you basically should avoid directly calling db.notes.put() to update a lot of times because that makes a revision each time.
That solution worked wonders, thank you.
Are these fields able to be removed or are they permanent? (I only see ways to add and not remove which might be by design?)
This isnāt a large issue, mainly wanting to remove the extra fields if the user resets the plugin or something similar.
Itās not currently designed for custom fields, so itās not possible to remove them via editingNote.update action at the moment.
yep, good point. Cleaning up is important.
The field prefix āx-ā is not sufficient for cleaning up.
The plugin name should be able to be inferred by the field names like āx-plugin-name-fieldNameā.
But I guess scanning all the notes to clean them up may take a while if the user has a lot of notes.
Another way to store custom data is to create separate docs something like:
{
"_id": "plugin:PLUGIN_NAME:<CUSTOM_DOC_ID>",
...(custom data)
}
The āCUSTOM_DOC_IDā can be arbitrary.
In this way, you can make a doc for each note that has custom data:
{
"_id": "plugin:PLUGIN_NAME:<NOTE_ID>",
...(custom data)
}
In this way, the app can support removing them anytime.
But I need further discussion on this because that makes the app complicated.
The database and sync could be broken.
I have also been looking at storing custom fields for notes to support some extra functionality.
Note that you basically should avoid directly calling
db.notes.put()to update a lot of times because that makes a revision each time.
While using db.notes.put() might not be a good idea for the revisions sake, it does not even seem to work. I have tried saving some custom fields using it and they never seemed to get applied, the example you provided works but as Iām trying to use custom fields on notes you arenāt currently editing this solution doesnāt seem to be a good idea. Would it be possible to apply the fields some other way or would I have to go with the separate docs?
You also mention that using the separate docs could break the database and sync, is there an actual risk of this even if I just use db.put and db.remove specifically on my custom docs, or is this just a warning you mention to be on the safe side?
Weird. Do you get a new revision in the returned value? It doesnāt filter custom fields.
Yea, you are right.
The separate docs would be better in this case.
Because updating a note will make another copy of the whole document. Thatās why you can roll back from the old revisions. Thatās kind of redundant for storing custom fields. Also, that would cause unexpected conflicts between devices.
So, plugin:PLUGIN_NAME docs would solve those issues.
Yes. The app should provide custom data APIs for the plugins so that you can avoid directly call db.put, which is dangerous. I donāt want to get reports from users screaming like āmy data gone!ā
I did some more testing and it seems like a new revision is created but the custom field is not stored.
What I tested
const id = "note:<a note id>"
const db = inkdrop.main.dataStore.getLocalDB()
const notes = db.notes
let note = await notes.get(id)
note["x-test"] = "test-val"
await notes.put(note)
The object returned by the promise of notes.put(note) contains a different rev than what is returned by the notes.get(id)
I then tried both await notes.get(id) and await inkdrop.main.dataStore.localPouch.get(id) and both of the returned objects are identical, also meaning that neither of them contained the custom field (I assumed that maybe notes.get() was filtering some fields when fetching).
Just for the sake of it I also tried updating one of the regular fields of the note alongside setting the custom field, the regular field was updated when calling notes.put(note) but the custom field was still note stored.
Thatās due to the Electronās remote object proxy:
So, you have to convert the remote object to a local object beforehand like so:
const id = "note:<a note id>"
const db = inkdrop.main.dataStore.getLocalDB()
const notes = db.notes
let note = await notes.get(id)
await notes.put({ ...note, "x-test": "test-val" })
That works perfectly, thank you!
It might be worth putting this as a note in the docs info about working with the DB. Iām probably not the only one that havenāt worked with Electron before, and this kind of info can be a bit hard to find if you donāt know what you are looking for.
Edit: I see now that there is some info about Remote Objects under the Accessing the PouchDB instance (Advanced) section but unfortunately the link with more information does not work anymore.
You are right, and thatās one of the reasons why itās not recommended to use low-level database APIs.
Please hold on storing custom fields to the note documents directly until the app officially supports plugin documents.
Fixed the broken link! Thanks.