Open M4tsuri opened 2 years ago
Could you try adding date_created
and date_updated
fields in the post body? e.g.,
let item = await user.items.custom.post({
"title": `test`,
"date_created": new Date().toISOString(),
"date_updated": new Date().toISOString(),
})
Also note that the current RSS3 SDK (till May 2022) is still using the RSS3 v0.3.1 API, which is about to be deprecated. The v0.4.0 API will be available soon. But the custom item feature is being taken down after some consideration. We'll release further announcement during this month and provide some suggestions on how to migrate for our developers.
/cc @DIYgod
Thanks for your solution, but this code still throws a Parameter error
.
As for the API changing, I checked out the v0.4.0 protocol and found that the custom item is replaced by a more generic Item
type. I wonder if I'm not misunderstanding.
BTW, current when syncing after posting, it seems that the SDK will pull the full content list and resign it. I think there can be heavy tradeoff when sync files for a user with many history posts.
@M4tsuri
this code still throws a Parameter error.
Sorry about this. I'm not quite sure about this API. I think you may take a look at this test file https://github.com/NaturalSelectionLabs/RSS3-SDK-for-JavaScript/blob/86b7d60e1536a84e07ced193bea405829c1cabd3/test/items/custom.ts for a reference if you really want to use it though we decided to deprecate it.
I checked out the v0.4.0 protocol and found that the custom item is replaced by a more generic Item type.
No. Starting from v0.4.0, there's no way to create a custom item on RSS3 Network. This is a big decision that RSS3 won't support posting content but only indexing and delivering content. If you want to post your custom items, you are very welcome to post them on our supported networks. We will give away more details on our website and community.
there can be heavy tradeoff when sync files for a user with many history posts.
True. In this version of design, the maximum size for a list file is 2MB; if exceeded, pagination will happen with an "identifier_next" field. We thought this size and sign mechanism would be tolerated for clients. But I have to admit that the custom item design has some flaws and imperfect implementation when looking back now. That's a part of reason that we take it down in the following versions.
RSS3 SDK version:
"rss3": "^0.8.19"
The code below can cause a 400 Bad Request:
Prenode returns:
It seems that there is an error when backend is parsing the repacked item list.
Thank you.