Page MenuHomePhabricator

Implement notification texts generation on the client
ClosedPublic

Authored by marcin on Jun 18 2024, 5:18 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 15, 8:26 PM
Unknown Object (File)
Fri, Nov 15, 7:13 PM
Unknown Object (File)
Fri, Nov 15, 7:12 PM
Unknown Object (File)
Fri, Nov 15, 7:12 PM
Unknown Object (File)
Fri, Nov 15, 7:12 PM
Unknown Object (File)
Wed, Nov 13, 3:41 AM
Unknown Object (File)
Fri, Nov 8, 6:48 PM
Unknown Object (File)
Fri, Nov 8, 12:49 PM
Subscribers

Details

Summary

This diff implements generation of notification texts for each recipient user.

Test Plan

Use the priviede hook in some client code that should generate notif (e.x. sendTextMessage). Log and examine the result

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Harbormaster returned this revision to the author for changes because remote builds failed.Jun 18 2024, 5:31 AM
Harbormaster failed remote builds in B29744: Diff 41451!
lib/push/send-utils.js
408–414 ↗(On Diff #41453)

This is a lot of params. Can you make it a param object instead?

lib/push/send-utils.js
275 ↗(On Diff #41560)

This is simple logic:

  1. Transform RawMessageInfo into MessageInfo
  2. Get parent threadInfo
  3. Resolve ENS and FC usernames
  4. Build notif texts
331 ↗(On Diff #41560)

This function does the same as above but for all users. Additionally for each user it prepares separate threadInfo as it is done on the keyserver.

381 ↗(On Diff #41451)

In next diff I will change it to return mapping from platform to array of notifications coupled with deviceID.

lib/push/send-utils.js
376 ↗(On Diff #41566)

notifTextsForMessageInfo expects array since it potentially will suport a case of notification coalescing. But now we don't do it on the client so we always pass one element array.

Does this diff represent "factoring out" some logic, or are we reproducing a limited subset of some logic? If either is true, can you link the original logic this was inspired by?

lib/push/send-utils.js
300 ↗(On Diff #41566)

Is there a task tracking this?

374 ↗(On Diff #41566)

Please replace "This" with something more specific. It's not clear what you're talking about

lib/push/send-utils.js
392–395 ↗(On Diff #41566)

Can we move it to a type? It's used multiple times here

lib/push/send-utils.js
300 ↗(On Diff #41566)

It is handled in D12539

lib/push/send-utils.js
275–317 ↗(On Diff #41566)

This is reproducing a limited subset of original logic that lives on the keyserver. Refer to: https://github.com/CommE2E/comm/blob/master/keyserver/src/push/send.js#L226-L296

333–345 ↗(On Diff #41566)

This is reproducing limited subset of original logic that lives on the keyserver. Refer to: https://github.com/CommE2E/comm/blob/master/keyserver/src/push/send.js#L695-L715

356–395 ↗(On Diff #41566)

This is reproducing limited subset of logic that lives on the keyserver. Refer to: https://github.com/CommE2E/comm/blob/master/keyserver/src/push/send.js#L134-L172

Extract parameters to object

Nit: when you linking code it's better to use the latest commit from the master, not the master branch as after some changes link will start pointing to different lines, and if someone needs context after a while it might get lost.

lib/push/send-utils.js
369–374 ↗(On Diff #41946)

nit: you can use PerUserNotifBuildResult but define perUserNotifTextsPromises as with let and use spreads but up to you

413 ↗(On Diff #41946)

why this spread is needed?

This revision is now accepted and ready to land.Jul 3 2024, 3:49 AM
lib/push/send-utils.js
413 ↗(On Diff #41946)

Makes the type writable