dashersw / dashersw/erste

Decide between the delegate pattern and event driven programming for components

Open
#8 0 comments 0 reactions 0 assignees View on GitHub
help wanted
Dominant language
JavaScript
Stars
284
Forks
32
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.