Inputs aren't generic across different backends about react-future

[sophiebits]

The fact that we're encouraging users to go to the DOM directly also prevents the creation of a custom <FancyInput /> component that mirrors the native <input /> API but does all the drawing, etc by hand.

[sebmarkbage]

This is part of having a generic and a blessed way of doing both FRP signals and FRP events in both directions. Preferably in a less imperative way.

<input value={...} /> // downwards signal
<input onChange={...} /> // upwards event

this.refs.myInput.getValue(); // upwards signal
this.refs.myInput.focus(); // downwards event

[haohcraft]

A naive question, what does FRP mean???

[vjeux]

@haohcraft Functional Reactive Programming

[jaredly]

👍 would love to see this

[ustun]

@haohcraft He means Functional Reactive Programming here, but FRP is also used for Functional Relational Programming in "Out of the Tarpit" paper. This usage is much less common though.

[nmn]

This sounds like a great Idea. But it would need more thought, as if it is done, it should be done for a lot more use cases than just getValue();

Also want to add that Async getDOMNode() is a great thing!

[dey-dey]

👍

[nmn]

So this issue was raised way before React-Native was annouced, so I guess I was being a little myopic.

At this point I think having a generic way to get and set values would be a great idea. That said, it would necessarily need to work with objects, kind of like setState.

Many components can have many different kinds of data that they store, returns and fire events for.

[moimikey]

I was initially confused by the two different means of actually getting an input value between the two during a code review (we're doing some investigatory spikes with React). aside from this.refs.myInput.getDOMNode().value seeming more like an abstraction, are there any caveats between that and e.target.value, or are they indefinitely 1-to-1? a getValue method seems to most intuitive, but my lack of core knowledge makes that a brittle opinion.

[sebmarkbage]

I don't think we'll actually end up doing this for built-ins since they will return the actual DOM node and therefore, we can't new methods to it. Instead, a generic version would use a getter.

I'll close this out because this isn't actionable, but feel free to reboot the conversation with a different proposal if we need more unification.