Feature request: ability to override the Input component of a TextField #12472

Right now I'd have to basically duplicate the code in TextField, but with my own Input component instead.

@jedwards1211 What's wrong with that? The TextField is a simple wrapper component to solve 80% of the use cases. It doesn't aim at being more. Recomposing the text field is definitely a great pattern, it's allowing people to be closer to the actual DOM, something you might need here.

As far as I understand the problem, I'm very tempted to label the issue "won't fix".

Well, what do you see as the downside of allowing people to override the individual components? It would be a small, very simple amount of code to support this so to me it seems like there's virtually no downside to it, and plenty of potential benefit.

I can easily release a fork of TextField as it's own package but I thought it wasn't very justified to create additional fragmentation in the ecosystem for such a small, non-breaking change. Especially since it wouldn't automatically stay consistent with API changes here. Though I hadn't thought that I may be able to just use Select for this, we'll see.

I'm happy to make the PR to do this btw, but I'm certainly not going to waste my time making PRs to this project anymore without any idea if they're likely to get merged

Well, what do you see as the downside of allowing people to override the individual components?

@jedwards1211 It's more about the direction we want to encourage people to go into. What's wrong about using FromControl, InputLabel, Input and FormHelperText over the TextField?

Regarding the integration with redux-form, you might not need a library for it: https://github.com/mui-org/material-ui/issues/8377#issuecomment-331893521

But we migrated to react-final-form:

import React from 'react'
import PropTypes from 'prop-types'
import TextField from 'web/modules/components/TextField'

function RFTextField(props) {
  const {
    autoComplete,
    helperText,
    input: { name, ...input },
    InputProps,
    meta: { dirty, error, submitError, submitFailed },
    ...other
  } = props

  return (
    <TextField
      error={Boolean((dirty || submitFailed) && (error || submitError))}
      {...input}
      {...other}
      id={name}
      name={name}
      InputProps={{
        inputProps: {
          autoComplete,
        },
        ...InputProps,
      }}
      helperText={dirty || submitFailed ? error || submitError : helperText}
    />
  )
}

RFTextField.propTypes = {
  autoComplete: PropTypes.string,
  helperText: PropTypes.node,
  input: PropTypes.shape({
    name: PropTypes.string.isRequired,
  }).isRequired,
  InputProps: PropTypes.object,
  meta: PropTypes.shape({
    dirty: PropTypes.bool.isRequired,
    error: PropTypes.string,
    submitError: PropTypes.string,
    submitFailed: PropTypes.bool.isRequired,
  }).isRequired,
}

export default RFTextField

Alright, encouraging one pattern doesn't mean we should prevent another when the overhead is low. What about adding some InputComponent, SelectComponent, FormHelperTextComponent, FormControlComponent, and InputLabelComponent properties?

The overhead I can think of is about making:

• the TextField source code harder to read
• add some more bytes down the wire

This might not be significant, so we should be good.

Yeah it is true that it would add more bytes, that's a concrete downside. Now that I read what TextField is doing, it's not as complicated as I thought so duplicating its behavior with a custom input for redux-form wouldn't be so bad. I was a bit worried at first that I would overlook something and burn time on it. Which is true to some degree, the error and helperText logic are a bit subtle.

I shouldn't have complained about whether a PR would get merged, because I always wind up with code I can use for myself even if it doesn't get merged. (I did release material-ui-popup-state btw)

Now that I read what TextField is doing, it's not as complicated as I thought so duplicating its behavior with a custom input for redux-form wouldn't be so bad.

@jedwards1211 Let me know what direction you want to take, I'm happy with both sides :).

I did release material-ui-popup-state btw

Awesome! I'm sorry I haven't answered yet on this topic yet. I have a backlog of items to handle that is growing. Do you want to link it in the documentation?

Yeah I'll make a PR for that soon!

@0maxxam0 funded this issue with $20. See it on IssueHunt