Projection's nested fields aren't being updated when subscribing to a query

[omazin]

Created a projection as follows:

  backend.addProjection 'gameInfos', 'games',
    id: true
    testGame: true
    host: true
    classIds: true
    createdAt: true    
    mode: true
    'scenario.name': true
    'scenario.labels.publish': true
    'scenario.labels.unpublish': true
    'scenario.scenarioName': true
    'scenario.playedAt': true
    'scenario.gameCategory': true
    'scenario.gameType': true
    'scenario.password': true
    'scenario.roles': true

Subscribed to a regular query:

   $games = @model.query 'gameInfos', someQuery
   @model.subscribe $games, =>
       @model.ref '_page.games', $games
       @page.render ...

All first-level nested fields, e.g. mode, host are being reactively updated. But the specified nested fields, e.g. scenario.name are not.
It will work fine if I pass just scenario: true into addProjection, i.e. all nested fields under scenario object will be updated reactively, but what if I only want a subset of the nested fields.

[ericyhwang]

Projections on sub-fields are not very well-supported currently:
https://github.com/share/sharedb/tree/v1.3.2#addprojection

They happen to work for fetches using sharedb-mongo, because the projection spec is directly mapped to a Mongo projection, which accepts the dot notation for sub-fields.

However, projections on sub-fields don't really work for subscriptions:

1. The code that handles projecting op components does not handle sub-fields.

   • sharedb/lib/projections.js

     Lines 59 to 62 in 8de6f3e

     	// The path has a first element. Just check it against the fields.
     	if (fields[path[0]]) {
     	result.push(c);
     	}

   • Doing so is tricky. The op projection code would need to handle op components with paths that are exactly the sub-field, a descendant of the sub-field, and an ancestor of the sub-field. It's doable, just tricky, and ideally with plenty of tests.
2. For query subscriptions with sharedb-mongo specifically, there's a "skipPoll" optimization that skips polling a query if it's certain that an op could not possibly affect the query.
   • https://github.com/share/sharedb-mongo/blob/595f092f53e2dc13c4c45f5dd89c66921e77bfbc/index.js#L916-L922
   • That may also need to be updated to account for projections on sub-fields, in a similar manner that accounts for descendant and ancestor paths.

I'll leave this open as a feature request, but I don't think me or the other active maintainer will have time to work on it in the next few months. If you're interested in tackling it, we can certainly advise!