-
Notifications
You must be signed in to change notification settings - Fork 17
Align notification responses format #147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Align notification responses format #147
Conversation
…hub.com:kuzzleio/sdk-javascript into develop-110-align-notification-responses-format
…notification-responses-format
Current coverage is 99.63% (diff: 100%)@@ develop #147 diff @@
==========================================
Files 16 16
Lines 1644 1652 +8
Methods 265 265
Messages 0 0
Branches 434 436 +2
==========================================
+ Hits 1639 1646 +7
- Misses 5 6 +1
Partials 0 0
|
…notification-responses-format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not at ease using a KuzzleDocument for notifications.
It works well for document notifications, but I see 2 problems:
- we'll soon add an "updated" field containing only the document changes, used by observers frameworks to quickly update user interfaces. This does not fit well with
KuzzleDocumentobjects - I think it's misleading to use a
KuzzleDocumentobject for message notifications, as these do not involve documents at all
|
I agree with @scottinet 's remark. It's handy to have a KuzzleDocument instance right in the Notification instance, but only when it's semantically consistent. Didn't we have a workshop on this topic? Do we need another one? |
|
I dont think we had a workshop and I believe we need one. |
|
Still need to discuss it, but some side thoughts included on the update case kuzzleio/kuzzle#485 |
|
Following our discussion: Notification objects will be extended this way:
i.e. {
"type": "document",
"error": null,
"status": 200,
"roomId": "91088e3125a9794073bdcf7b882bb39c",
"requestId": "e548ab40-1d99-4c86-8afc-36fd5638bb5b",
"index": "index",
"collection": "col",
"controller": "write",
"action": "update",
"protocol": "websocket",
"timestamp": 1479899117280,
"metadata": {},
"scope": "in",
"state": "done",
"room": "91088e3125a9794073bdcf7b882bb39c-12213aafe59a4f4a238d00903d03bfb8",
"document": {
"collection": "col",
"id": "AViQ3Hbm_UlxC0CPmdJ2",
"content": {
"foo": "bar",
"_kuzzle_info": {
"author": "-1",
"createdAt": 1479899117284,
"updatedAt": null,
"updater": null,
"active": true
}
},
"changed": {
"foo": "bar"
},
"headers": {}
}
}Other discussions
|
…otification-responses-format
…velop-110-align-notification-responses-format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔
|
|
||
| if (data.controller === 'realtime') { | ||
| data.type = 'user'; | ||
| data.user = {count: data.result.count}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not seem to match the PR description.
The result field is removed, replaced by a count property.
Here, the result field is replaced by a user property, seemingly containing a count property.
Am I next to the plaque?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question for me, but I did not follow the discussion about that, so I may be wrong...
Can you either fix that, or fix the PR description, depending what is really wanted ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The initial PR description has been kept for history but the actual implementation matches the one we have aggreed on.
So, no result anymore, but a new field named as the new type property. In this case, it is normal we have a user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the ref: here is the updated one: #147 (comment)
|
@benoitvidis I let you resolve the conflicts before merging to develop. |
…notification-responses-format
…notification-responses-format
|
This should be merged, no? |
fixes #146
⚠️ taken from #42
Notifications
Document notifications
writecontrollerThe
resultentry is replaced with adocumentone, which is aKuzzleDocumentobject:{ "error": null, "status": 200, "roomId": "91088e3125a9794073bdcf7b882bb39c", "requestId": "e548ab40-1d99-4c86-8afc-36fd5638bb5b", "index": "index", "collection": "col", "controller": "write", "action": "create", "protocol": "websocket", "timestamp": 1479899117280, "metadata": {}, "scope": "in", "state": "done", "room": "91088e3125a9794073bdcf7b882bb39c-12213aafe59a4f4a238d00903d03bfb8", "document": { "collection": "col", "id": "AViQ3Hbm_UlxC0CPmdJ2", "content": { "foo": "bar", "_kuzzle_info": { "author": "-1", "createdAt": 1479899117284, "updatedAt": null, "updater": null, "active": true } }, "headers": {} } }Users notifications
The
resultfield is removed, replaced by acountproperty. Previously, the roomId was part of theresultelement, which is now discarded as this information is already available to the user.{ "error": null, "status": 200, "roomId": "91088e3125a9794073bdcf7b882bb39c", "requestId": "52ea3832-9e0a-443c-85a5-c1330c24f111", "index": "index", "collection": "col", "controller": "subscribe", "action": "off", "protocol": "websocket", "timestamp": 1479899263293, "metadata": {}, "room": "91088e3125a9794073bdcf7b882bb39c-12213aafe59a4f4a238d00903d03bfb8", "count": 1 }Other (token expired) notifications
The only other notification is the token expired one, which does not include any
resultelement.Other change
KuzzleDocument
kuzzleanddataCollectionproperties are not enumerable anymore.changedproperty is not implemented as it requires some extra development from Kuzzle side.