Pre-release 1.4 is now available for testing (Updated 23/11/20)

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:

  • 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)

Thanks @laurent - do we now have two beta/pre-release tracks, 1.3.n and 1.4? Or do the 1.4 releases also incorporate the 1.3.n fixes?

1.3 is now released officially, so there's only one pre-release which is 1.4.

And yes, 1.4 pre-release will incorporate any fix from 1.3.

Ahh, I missed the 1.3 release - thanks for the clarification!

By the way, I've added a note regarding the webclipper API:

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:

If anyone's using this API and has troubles with it please let me know. @foxmask, @rxliuli maybe?

1 Like

This is really a big change, which means that something needs to be modified. . . For me, including

  1. Get all directory lists in vscode and joplin charts must add ?as_tree=1 to restore the old behavior
  2. To query all notes, a new method must be added in joplin-api npm
  3. 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?

Also ask, has this point been revised?

I'll try soon

New version is available now. The plugin system didn't work in the previous release but it should be fine now.

  • New: Api: Added ability to watch resource file
  • New: Api: Added way to get the notes associated with a resource
  • Improved: Plugins: Force plugin devtool dialog to be detached

"cursor" because it tells you where you are in the feed.

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. . .

When I have 788 notebooks in the root directory, there will be obvious freezes when I select the notebooks

log.txt (1002.3 KB)

/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

  1. It is also obtained by page, which is not necessary for obtaining all the attachment information of a note
  2. 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

{"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.

Thanks, will check

Maybe, but I set /notes/${id}/tags and /notes/${id}/resources on the application layer api to always return T[] instead of PageData <T[]>

+1, this error also appeared on my side

can't we bypass the pagination ?
As I already deal with that, it's annoying :frowning: