Skip to content
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

Decide between the delegate pattern and event driven programming for components #8

Open
dashersw opened this issue Mar 13, 2017 · 0 comments

Comments

@dashersw
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant