Text input? about componentkit

[adamjernst]

Sorry for the delay in getting back to you! This is a complicated one since text fields have so much state. It's not possible to box up and restore that state, which is what you'd need to do if you wanted to make the view an implementation detail.

Inside Facebook, we have a "stateful view wrapper" component that you can use with views like these. It basically makes a CKComponentController instance responsible for storing a single instance of the view. You lose the view-reuse abilities of Components, but you gain the ability for the view to hold state outside of the reactive immutable component flow.

I'm looking over what it would take to move that component into this repo and open source it. For now, though, you could try writing it yourself!

[smiLLe]

@adamjernst could you give some more details please?

Lets say i need an UITextField. whats the best lifecycle method in the controller to create this view? UI elements should be created on the main thread but -init is called from a separate thread.
At what time should i add/remove the TextField to the view hierarchy? -componentDidAcquireView add, -componentWillRelinquishView remove?

[leoschweizer]

I'm also very interested in this topic. Currently, I'm trying to make a good SwitchComponent-Implementation (for UISwitches). The tricky thing is that the UISwitch can change it's on-state through user-interaction without affecting the component state.

So my general idea was to have a component which creates a reusable, blank UIView and an according component controller which instantiates a UISwitch. The component controller then adds and removes its UISwitch to and from the reusable UIView container in componentDidAcquireView.

If anyone is interested in taking a look at the source code, I pasted it here: https://gist.github.com/leoschweizer/667bf1476e25333459a2

However, at least on my old iPhone with iOS 7, this sometimes causes flickering as the UISwitch views get (re)added to the container view.

Also, the UISwitch views could be reused perfectly if it were possible to mutate the view attributes of a component internally (read: when the switch changes it's state, the view attributes would have to be mutated - then reuse would work like a charm). However, that doesn't seem to be possible.

I appreciate any input on how to make this implementation better. And once a satisfying state is reached, I also wouldn't mind making a pull request for it if desired.

[smiLLe]

@leoschweizer do you have a new version of your gist or are you still using this implementation?

[leoschweizer]

@smiLLe no I don't have a better solution yet. However, I'm totally not satisfied with the current one due to the UI flickering and the unnecessarily restricted view reuse 😞

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[ocrickard]

With the open sourcing of stateful view components you should be able to build this now. It's what we use internally for text views.