There are few changes so far as it's mainly to check that the Lerna switch didn't break anything. I'm using it already and haven't noticed any issue so far.
IMPORTANT: If you use the Clipper API, please note that there are a few breaking changes in this version. See this link for more information: https://github.com/laurent22/joplin/pull/3983
New: API: Adds ability to paginate data (#3983)
New: Adds spell checker support for Rich Text editor (#3974)
Improved: Change Markdown rendering to align with CommonMark spec (#3839)
This is really a big change, which means that something needs to be modified. . . For me, including
Get all directory lists in vscode and joplin charts must add ?as_tree=1 to restore the old behavior
To query all notes, a new method must be added in joplin-api npm
Search search is a problem for me. If vscode does not support continuous addition of elements to the search result list, then I can only make requests in a loop (this is not a big problem, because no one wants to see the results after 100, if there are So many, more specific keywords should be used)
What is cursor? Does it mean the offset of the next page? The name is very weird. Generally, ʻoffset+size/limitorpageCurrent+pageSize` is used to find data in pages, right?
This seems to be very different from the normal paging query. You can only query the data of the next page through cousor. Does this mean that you can never directly query the data of offset: 100, limit: 10 through the api? Is there any special reason for using this method? Or is there any problem with using offset+limit to implement paging query?
Okay, I know why I use cousor, but I'm not sure if there will be a scene that suddenly jumps to a certain page. . .
/notes/${id}/tags This api should not be paged. Generally, the number of tags for a note cannot exceed 10, and it is absolutely impossible to need the amount of data to be paged.
In addition, let me confirm one point. Do tags and attachments need to be paged by default? Are there parameters like as_tree like folder api to restore the old behavior?
/notes/${id}/resources Contains two questions
It is also obtained by page, which is not necessary for obtaining all the attachment information of a note
Request: GET /notes/20873d8c1dd24ce288e0076e080f7aae/resources?token= An error occurred Error: Error: SQLITE_ERROR: no such column: parent_id: SELECT id,parent_id,titleFROMresourcesWHEREid = ?: a4f6af53beb6436891270361429ba0b6
we have an error, I quickly saw in the footer of the app and could confirm when trying to request the API
NoteResource.deleteByResource is not a function
curl -XDELETE http://127.0.0.1:41184/resources/b11950f661d04855bbc5e84d9da0e0ad?token=xxx
{"error":"Internal Server Error: NoteResource.deleteByResource is not a function: \n\nTypeError: NoteResource.deleteByResource is not a function\n at Function.batchDelete (/tmp/.mount_JoplinLba3YZ/resources/app.asar/node_modules/@joplin/lib/models/Resource.js:277:23)"}
(joplin-api) ✔ ~/Projects/joplin-api/joplin-api [master|✚ 4…3]
offset/limit support shouldn't be too hard to implement if it's ever needed, but in general it's better to iterate using a cursor as it works even if the data changes. Perhaps there could be support for a "page" query parameter like in the StackExchange API.
In general you should have some wrapper code that handles all paged data. For consistency all end point that returns multiple objects is paged even if there are only a few objects being returned.
That being said you're always free to assume that a dataset will not exceed 100 items, for example for tags, and just look at the "items" property.
