Add api to manually trigger events

[alpha0010]

When, for example, implementing custom buttons in the top bar, one cannot use the event system from this library. This causes an awkward situation where text buttons route through the built in navigation system, but specialized buttons cannot.

The changes here add the ability to trigger (fake) events from javascript side, allowing all logic to route through the same path.

Navigation.events().notifyEvent('xxx_EventName_xxx', { event: 'data' });

[alpha0010]

Devs, any feedback? Is there a different solution I should be using?

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[alpha0010]

Still looking for feedback from devs.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[alpha0010]

Looking for feedback from devs.

[guyca]

Hey @alpha0010
I'm really sorry this PR slipped by me. We've had a similar system in v1 and botched it because we felt RNN shouldn't include a pub-sub implementation, and I still hold that position today. My main concerns are:

1. Feature creep
2. Potential performance issues - multiple components handling the event one after the other, potentially triggering more logic (setState, dispatch action etc) which could contribute to a busy JS thread.

I think implementing a pub-sub is less than an hours work and as it's not RNNs' main concern, it should not be part of the code base.

Perhaps we should document the best practices for this use case.

WDYT?

[alpha0010]

I think triggering actions from a side menu or the top bar would be a relatively common use case. From the user (non-RNN dev) side, it feels odd to have an event system that handles only a bit of this. It makes more sense in the code (based on where native events come in).

Your reasons for avoiding this type of system in RNN make sense to me. However, it is still a situation closely related to navigation (from the issue tracker, appears others have had similar questions), so having best practices documentation would be great.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[guyca]

@alpha0010
#5612 adds support to update component props via mergeOptions. I believe this achieves something similar to what you had in mind.