You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently components extend EventEmitter so that they can fire arbitrary events. This makes it a great companion to the DOM, since DOM is also event driven. But almost all of the current modern frameworks have a delegate pattern where you register a method of a parent component in a child component for later use. This is also on par with native iOS SDKs. Plus, the delegate pattern makes it easy to introduce typing in your code since it usually is operated with interfaces that define how delegates should be implemented.
We shall decide whether we want to keep the current event structure or move to the delegate pattern for our components.
An example would be the InfiniteScroll component, where it emits the event load for the listeners—most likely one, single, parent list view—to load more items. You can never be sure if the parent listens to the correct event and listens to it exactly once. In this scenario, is it favorable to use events for this? What would be the impact if we just went for the delegate pattern of registering a callback?
An example for this is the NavBar component, where a consumer of this component needs to override the methods onBackButtonTap and onMenuButtonTap to act upon these user interactions.
The text was updated successfully, but these errors were encountered:
Currently components extend EventEmitter so that they can fire arbitrary events. This makes it a great companion to the DOM, since DOM is also event driven. But almost all of the current modern frameworks have a delegate pattern where you register a method of a parent component in a child component for later use. This is also on par with native iOS SDKs. Plus, the delegate pattern makes it easy to introduce typing in your code since it usually is operated with interfaces that define how delegates should be implemented.
We shall decide whether we want to keep the current event structure or move to the delegate pattern for our components.
An example would be the
InfiniteScroll
component, where it emits the eventload
for the listeners—most likely one, single, parent list view—to load more items. You can never be sure if the parent listens to the correct event and listens to it exactly once. In this scenario, is it favorable to use events for this? What would be the impact if we just went for the delegate pattern of registering a callback?An example for this is the
NavBar
component, where a consumer of this component needs to override the methodsonBackButtonTap
andonMenuButtonTap
to act upon these user interactions.The text was updated successfully, but these errors were encountered: