docs: Reverse recommendation for controlled inputs

[rschristian]

Reverses the recommendation for uncontrolled components over controlled, which I think everyone's in agreement with?

Do we want to also make a note of the issues that exist for controlled inputs in X?

[JoviDeCroock]

Controlled components don't really exist in Preact, issues are things where you bail out of rendering resulting in the same value.

[rschristian]

That was sorta my point, though I was trying to be a tad less bleak.

Do we want to out-right say they're unsupported? Problem is that a fair number of React folks expect that as a table-stakes feature, and for certain use cases (or if you squint hard enough at others), Preact can get the job done without them. A lot of users just assume they need them (which is a separate problem).

I just worry that being that up front about it might scare people away unnecessarily.

Edit: That being said, I'm happy to alter this to whatever. Just my 2 cents.

[JoviDeCroock]

Yes, no I agree with you. I guess we could be upfront about returning to the same input and how to work around that (i.e. use an object-state or what's said here at the end)

[rschristian]

I think that's reasonable.

Alrighty, I'll work on rewording this block entirely, get a bit more actionable info in here.

[rschristian]

Sorry, unrelated but missed in #1162 as we for some reason weren't calling btoa on this. Grep didn't find any other btoa references so I assumed we were all covered.

[rschristian]

@JoviDeCroock I ended up re-using your example as you suggested, let me know if you disagree with any of the language or the reference to your blog post. I thought it could be useful, but perhaps it's too much context? Not sure.