Summary:
@public
We need that because gonna add much more event-related stuff, so it deserves separate buck target.
Reviewed By: mdvacca
Differential Revision: D8831547
fbshipit-source-id: 616581b39b425a49302d5f7f86267e62b0d58389
Summary:
Using `EventHandlers` name was a bad idea, and I cannot tolerate it anymore.
The worst part of it is that when you have a collection of `EventHandlers` objects you cannot use plural word to describe it because `EventHandlers` is an already plural word.
And, this object is actually an event emitter, the thing on which we call events.
Reviewed By: fkgozali
Differential Revision: D8247723
fbshipit-source-id: b3303a4b9529bd6d32bb8ca0378287ebefaedda8
Summary:
Pretty trivial; new type of mount item & new method in the component protocol.
The default implementation in `UIView+ComponentViewProtocol` does nothing.
Reviewed By: fkgozali
Differential Revision: D8053355
fbshipit-source-id: a0418edf17ca75c4b94942b04acd93f3ea5d27e0
Summary: We do not have a clear strategy how to deal with layout-only (view-less) components. Even if this particular solution is not so fancy, it prevents crashing during text rendering.
Reviewed By: mdvacca
Differential Revision: D7785885
fbshipit-source-id: f3ed8988aa2b41349fd1693c2a7f8c9368daee43
Summary:
MountItem is a small granular light-weight instruction describing a change in the component view tree.
All instruction are supposed to be small and standard. All additional logic must be implemented in component view subclasses.
No more opaque and untyped objcblocks.
All that allows mounting manager to control and optimize an execution of those items (eventually).
Besides that five we probably will need `perform imperative instruction` (for execution something like `scrollTo`) and `update local data` (for updating local state of something like text input).
Reviewed By: mdvacca
Differential Revision: D7507518
fbshipit-source-id: 745b93125231a02cbc152cfa6c6baf423d100f81
Valentin Shergin