-
Notifications
You must be signed in to change notification settings - Fork 25
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
Added optional source to GeneratedEventWrapper #92
Added optional source to GeneratedEventWrapper #92
Conversation
…urce if source is passed with eventWrapper
LGTM to me but let's add a test exactly for our use case |
@@ -142,7 +151,7 @@ const generateEventing = | |||
generateEvent: (eventWrapper: GeneratedEventWrapper) => { | |||
const mappedEvent = { | |||
event: eventWrapper.event, | |||
source: { | |||
source: eventWrapper.source ?? { |
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.
This change is a little weird, because we already support the timeStampOverride here, which is now completely ignored if the optional source is passed in.
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.
This kind of comes down to what we want the behaviour to be? :D
In this case it seems we just want to "forward" the event to a handler further up in the tree. In that case should the overrides apply as initially the event was likely created using bubble
?
But perhaps we need another way to just "bubble" those events further? It's almost like just doing this?
forward: (eventWrapper: EventWrapper) => {
return eventingRef.current.bubble(eventWrapper);
},
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.
This change is a little weird, because we already support the timeStampOverride here, which is now completely ignored if the optional source is passed in.
We can also turn it around to check for timeStampOverride first, and then source. otherwise fallback to default which is {inputType: InputType.programmatic, timeStamp: Date.now()}
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.
This kind of comes down to what we want the behaviour to be? :D
In this case it seems we just want to "forward" the event to a handler further up in the tree. In that case should the overrides apply as initially the event was likely created using
bubble
?But perhaps we need another way to just "bubble" those events further? It's almost like just doing this?
forward: (eventWrapper: EventWrapper) => { return eventingRef.current.bubble(eventWrapper); },
this is kind of what we wanted to achieve.
Closing as intercepter pattern was implemented in #93 |
We are currently integrating Jana into Outlook Web(OWA) and we need a way to catch a NovaEvent and then bubble it to parent provider if we dont want to deal with it. We are doing this by calling
generateEvent(event)
, but with currentgenerateEvent(event)
, source is generated on each call, which means we will lose metadata aboutsource
if it already exists in the event.By adding a optional field
source
, we can generate only ifsource
is not defined.