Input fields component

[kaievns]

we also need a generic input field component that looks something like this:

<Input
  type={ "text" | "password" | "checkbox" | "radio" | "textarea" | "select" | "multi-select" | ... }
  label="Some textual value"
  placeholder="some text"
  required= { true }
  pattern={ ".... " }
  schema={ json schema props value }
  ref={ "text-name" | e => this.smth = e }
  error="Validation error"
  />

depending on the type or schema this should generate the correct input block, along with an INPUT, SELECT or TEXTAREA field (later on SELECT will be replaced with pretty drop-downs and stuff), a label and necessary attributes.

the component itself should have the following methods exposed so it would be easier to deal with later on:

class Input extends React.Component {
   .....
   get value() {
     return this.refs.innerInput.value;
  }
  set value(value) {
    this.refs.innerInput.value = value;
  }
}

[nwinch]

I think it would be cleaner to separate these into multiple components using HTML tag names as a concern divider.

So input can accept the following types:

<Input type={ "text" | "password" | "checkbox" | "radio" } />

And then do a separate component for textarea and also select, as they are different tags with their own unique attributes and functionality.

It is definitely possible to roll them all up in one, but it will make it easier in the long run to maintain and update to have them separated I think.

[kaievns]

you're right it is a bit of a pain to put under the same component, but it worth it in the long run. i've done this multiple times and it plays out beautifully.

basically the idea is that all the input fields share a lot of common things in them, like labels, whole input blocks, values access, names, refs and so on. so having a uniformed surface area helps a lot in this regard. especially as we're stepping into the territory of automatic generation of sets of those input fields from json schemas.

branching things internally to INPUT, TEXTAREA, SELECT, etc. is pretty easily solvable via a simple strategy pattern. you basically have sub-components that provide specific types. in the end you will have pretty much the same separation as you would build them as separate components. but on the flip side you'd keep a uniformed API surface, reused common code, etc.

basically it is the same thing you're talking about, but one abstraction level up

[nwinch]

Yep, sounds good to me :)

[gilmoreorless]

I'm with @MadRabbit here. Having a single API surface area for the caller is better. The fact that a huge range of form fields boil down to just 3 HTML tags is a quirk of history (and a rather annoying one at that). I'd rather not replicate that mess as an API (especially given the wide range of HTML5 input types that have been shoved onto the <input> element: range, number, tel, email, date, time, datetime, etc.)