Reset context

[pgn-vole]

Question Area

[ ] App Directory
[ X] API
[ ] Context Data
[ ] Intents
[ ] Use Cases
[ ] Other

Question

Reseting context to an initial value doesn't seem to be covered in the API. A typical use case is when context is used as filter and the user disable filters. Any applications listening to that context should, I believe, be aware of that filtering beeing disabled.

console.log(fdc3.getCurrentContext()) // `null`, nothing whas been broadcasted yet

//User select an instrument
fdc3.broadcast({  type: 'fdc3.instrument', id: {  ric: 'VOD.L' }})

//User unselect instrument
?

In the above use case, how can an application reponsible of controlling the filters, reset the instrument context to null ?

[rikoe]

@pgn-vole can't you just broadcast null?

[kriswest]

@pgn-vole <https://github.com/pgn-vole> Is fdc3.getCurrentContext() a thing? I don't see it in the spec/docs. There is however fdc3.getCurrentChannel() <https://fdc3.finos.org/docs/api/ref/DesktopAgent#getcurrentchannel> and channel.getCurrentContext(); <https://fdc3.finos.org/docs/api/ref/Channel#getcurrentcontext> @rikoe Broadcasting null would/could work for channel.getCurrentContext(), but, as a channel retains the last context of each type and null doesn't have a type, there might be issues with channel.getCurrentContext(type): https://fdc3.finos.org/docs/api/ref/Channel#getcurrentcontext That said, I think that might not matter a whole lot (it would return the last context of a valid type, or null if not specified. The alternative would be to broadcast an instrument with a null id I suppose (which doesn't reset you to the same state as you started in). Hence, I've come full circle and agree with broadcasting null.

…

On Thu, 28 Jan 2021 at 11:15, Riko Eksteen ***@***.***> wrote: @pgn-vole <https://github.com/pgn-vole> can't you just broadcast null? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#301 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM7PBD5J5FSG6IDH6RLRY3S4FBNHANCNFSM4WON6RJQ> .

-- Kris West Director of Solutions Engineering [image: Cosaic] +1 (800) 821-8147 kris@cosaic.io Cosaic.io: <https://cosaic.io/> ChartIQ <http://cosaic.io/ChartIQ> + Finsemble <http://cosaic.io/Finsemble> Upcoming Webinar: Finsemble and Pictet Asset Management January 14, 10:00 am EST REGISTER NOW → <https://cosaic.io/webinars/upcoming-webinar/>

[pgn-vole]

@pgn-vole can't you just broadcast null?

The signature of addContextListener doesnt't allow the context to be null so at the moment, unless by diverging from the specification, we can't do that.

Morever by simply dispatching a null context we miss one use case: How can a consumer of a specific context type capture that the context has been nulified?
Example of that use case:

fdc3.addContextListener('fd3.instrument', () => {
  // I wish to reset the UI when an instrument is unselected
})

I thought of 2 solutions:

Solution 1

Like @kriswest suggestion, one could broadcast an instrument property with "null" properties:

publisher:

fdc3.broadcast({
  type: 'fdc3.instrument',
  id: null,
})

consumer:

fdc3.addContextListener('fd3.instrument', (context) => {
   if (context.id === null) {
     //reset the UI
   }
})

That's an easy solution, which works with current API spec. The context shape specification would have to be modified to allow the id propertyt to be null though.

Solution 2

An alternative solution would be to broadcast a null context by extending the signature of broadcast and addContextListener.

addContextListener: Would allow the context argument to be null
broadcast: Would allow to hint the type via a parameter instead of relying on the type property.

publisher:

fdc3.broadcast('fdc3.instrument',null)

consumer:

fdc3.addContextListener('fd3.instrument', (context) => {
   if (context === null) {
     //reset the UI
   }
})

[kriswest]

As per comments on #361 we might be better served to create a NullContext context for this. We wouldn't have to change any API signatures, it has other potential uses and you can filter for it as a context type (so you can choose to process it or ignore it).

[pgn-vole]

It should do the job and is backward compatible so sounds goo to me!

[rikoe]

So what would this look like? { "type": "fdc3.nullContext" } or { "type": "fdc3.empty" } or something like that?

If so, I think we should raise a PR for this and get it added to the standardised context types. @pgn-vole would you be willing to do that? (Especially taking care of adding to the docs and published json schemas.)

[pgn-vole]

Happy to take ownership.

{ "type": "fdc3.nullContext" } looks good to me.
However I think that we need to add be able to anotate which type of context was nullified because channels can hold multiple contexts of various types .

Given a scenario:

• 2 contexts are assigned to a channel : fdc3.instrument and fdc3.contact
• a intrument picker wish to reset the currently viewed instrument by dispatching a null context.
• a "contact context" consumer wants to ignore the reset of the instrument context because it it is only interested by contacts.

To support that scenario we could augment the null context model to add a context type that has to be nullified:

{
  "type": "fdc3.nullContext,
  "name": "<contextType>" 
}

Example usage:

Instrument context consumer

fdc3.addContextListener((context) => {
  if (context.type === 'fdc3.nullContext' && context.name === 'fdc3.instrument') { 
    resetInstrumentView()
  }
})
fdc3.addContextListener((context) => {
  if (context.type === 'fdc3.nullContext') {
    updateInstrumentView(context)
  }
})

Contact context consumer

fdc3.addContextListener('fdc3.nullContext', (context) => {
  if (context.name === 'fdc3.contact') { 
    resetContactView()
  }
})
fdc3.addContextListener('fdc3.contact', (context) => {
  updateContactView(context)
})

Without that anotation, given the above scenario, the instrument and contact context consumers would not be able to know whether they should reset their UI.

[kriswest]

Good point @pgn-vole, if you had added a typed context listener, e.g.:

const contactListener = fdc3.addContextListener('fdc3.contact', contact => { ... });

then you would not receive the NullContext at all.

Can you refine your use-case description to confirm the need for a per-type reset (e.g. of a filter)? We should be careful to stick to real-world use-cases with examples so that we don't complicate the standard needlessly. Hence, do you anticipate resets of just a particular type in a real-world scenario, rather than just a reset of the channel as a whole?

If we end up confirming that a per-type reset is needed, then I'd rather not use the name field to indicate type. Rather, it should be a field that can support referencing multiple types (if you can reset one, why not more than one), OR (to support typed listeners) we should consider using an Object of the type you wish to reset with a particular id value (it has to be an object in the context schema, but we could modify the context schema to allow it to also be a NullContext or other value to indicate the reset.

Thoughts?

I'll submit a PR shortly for #361 that will define a NullContext schema that you could reference.

[kriswest]

See #375 for the Null context type

[kriswest]

A Standards Working Group vote is needed on this issue; there are two options to choose from, or the issue can be closed.

Options

1. (🎉) Use the fdc3.nothing type to reset the last context on the channel AND allow an additional field to specify a particular type to reset, e.g. {type: 'fdc3.nothing', subType: 'fdc3.contact'}
2. (🚀) use the fdc3.nothing type to reset the last context on the channel AND allow context types to be transmitted with an a null id to reset that type. Hence, context schema changes such that:

     "id": {
       "type": "object",
       "additionalProperties": { "type": "string" }
     }

   changes to:

     "id": {
        "type": ["object","null"]
        "additionalProperties": { "type": "string" }
      }

3. (👎 ) Close issue and do not allow context on a channel to be reset

Please vote with 🎉 for option 1, 🚀 for option 2. and 👎 to close the issue. The vote will be kept open until a few days after the next SWG meeting (Thursday 22nd July 2021).

[pgn-vole]

Thanks for the proposal Kris. To revert to your question about real world use case - this is about filters. At the moment there is no obvious way for UIs to sync up their states upon reset of a particular context type (i.e clear up Client filter while keeping Instruments one enabled).

Considering that they are opening in modify the shape of FDC3 Contexts, I would suggest a "2.b" option which in my view is a mix of both world:

• Allow context types to be transmitted with an a null id to reset that type. Hence, context schema changes such that:

  "id": {
     "type": ["object","null"]
     "additionalProperties": { "type": "string" }
   }

This would allow to not touch the context listener method signature while allowing contexts, of specific type, to be reset without the need to introduce a dedicated context type for that single purpose.

[kriswest]

After the last SWG meeting (#459), and based on the informal votes received, it was decided to remove this issue from the FDC3 2.0 milestone - but not to close it to allow discussion to continue or a PR to be submitted for consideration.

[kriswest]

Given the workarounds available and the lack of an appetite to add API functionality to enable this use case by other means, the decions was taken at meeting #867 to close this issue. See the meeting minutes for further info:

• Standard WG Meeting - Nov 30th, 2022 #867