shvets-sergey / handykit Goto Github PK

'presenterName' is "magic" property which carry with it a lot of background functionality that can be broken at some time. On other hand it ensures that presenter will listen to the events as soon as it created.

Need more thoughts.

Go with React approach for state and data to enforce the same API for presenter/view interaction.

Idea: to have similar to react view state object for the presenter and keep there everything needed for state of component which presenter holds. Having this, we can introduce shouldComponentUpdate automatically, plus it will be easier to test.

When creating views in "react" way it is important to be able to put stubs and implement them later with functionality. Must be extremely useful for bigger teams

Combine with a state of presenters and adding FRP can turn this into real powerful tool. Imagine when you have an object (e.g. contacts list) and in presenter you just trigger refresh and as soon as data arrived it automatically redraw UI, no callbacks? Oh, this is a dream!!

Add ability for 3rd party libraries (e.g. Phonegap) send events to the eventBus of all presenters.

For now there is only one root component, which makes impossible to refactor already existing application. Need to find a way to have multiple components in the DOM. For now, 'updateDOM' will fail with this approach.

All callbacks that passed to the view need to be called with context of presenter. So, it is a good idea to bind this functions to presenter automatically.