There are three answers here, depending on the version of React you're (forced to) work(ing) with, and whether you want to use hooks.

First things first:

It's important to understand how React works, so you can do things properly (protip: it's super worth running through the React tutorials on the React website. It's well written, and covers all the basics in a way that actually explains how to do things). "Properly" here means that you're not writing a web page, you're writing the user interface for an application that happens to be rendered in a browser; all the actual user interface work happens in React, not in "what you're used to from writing a web page" (this is why React apps really are "apps", not "web pages").

React applications are rendered based off of two things:

1. the component's properties as declared by whichever parent creates an instance of that component, which the parent can modify throughout its lifecycle, and
2. the component's own internal state, which it can modify itself throughout its own lifecycle.

What you're expressly not doing when you use React is generating HTML elements and then using those: when you tell React to use an <input>, for instance, you are not creating an HTML input element, you are instead telling React to create a React input object that happens to render as an HTML input element when you compile your React app for the web, with event handling that is controlled by React.

When using React, what you're doing is generating application UI elements that present the user with (often manipulable) data, with user interaction changing the state of your application in a way that you define - actions performed by the user may update a component's props or state, which React uses as a signal to generate a new UI representation for changed components, which may cause an update of part of your application interface to reflect the new state.

In this programming model, the app's internal state is the final authority, rather than "the UI your users look at and interact with": if a user tries to type something in an input field, and you did not write anything to handle that, nothing will happen: the UI is a reflection of the application state, not the other way around. Effectively, the browser DOM is almost an afterthought in this programming model: it just happens to be a super convenient UI framework that the entire planet is virtually guaranteed to have access to (but it's not the only one React knows how to work with)

A specific example

So with that covered, let's look how a user interacting with an input element works in React. First, we need to get to having a UI element for the user to interact with:

1. You wrote a component to manage (i.e. both store and present) some string data for your users, with an onChange function for handling user data.
2. Your component's rendering code is used by React to generate a virtual DOM that contains an input component (not a DOM <input> element), and binds your onChange handler to that component so that it can be called with React event data (so note that this is not a DOM change event listener, and does not get the same event data that regular DOM event listeners do).
3. The React library then translates that virtual DOM into a UI users can interact with, and that it will update as the application state changes. Since it's running in the browser, it builds an HTML input element.

Then, your user tries to actually interact with that input element:

1. Your user clicks on the input element and starts typing.
2. Nothing happens to the input element yet. Instead, the input events get intercepted by React and killed off immediately.
3. React turns the browser event into a React event, and calls the onChange function for the virtual DOM component with the React event data.
4. That function may do something, based on what how you wrote it, and in this case you almost certainly wrote it to update the state of your component with what the user (tried to) type.
5. If a state update gets scheduled, React will run that state update in the near future, which will trigger a render pass after the update.
6. During the render pass, it checks to see if the state is actually different, and if so, it generates a temporary second virtual DOM, which it compares to (a part of) your application's virtual DOM, determines which set of add/update/remove operations it needs to perform on you application's virtual DOM so that it looks the same as the new temporary one, then applies those operations and throws away the temporary virtual DOM again.
7. It then updates the UI so that it reflects what the virtual DOM now looks like.
8. And after all of that, we finally have an updated DOM on the page the user is actually looking at, and they see what they typed in the input element.

So this is completely different from the regular browser model: instead of the user updating the UI data by typing into a text box first and our code reading "the current value of that text box" to figure out what the state is second, React already knows what the state is, and uses events to update the state first, which leads to a UI update second.

And it is important to remember that all of this happens effectively instantly, so to your user it looks like they typed text into an input element in the same way they would for any random web page, but under the hood things couldn't be more different while still leading to the same result.

So, with that covered, let's look at how to get values from elements in React:

Component classes and ES6 (React 16+ and 15.5 transitional)

As of React 16 (and soft-starting with 15.5) the createClass call is no longer supported, and class syntax needs to be used. This changes two things: the obvious class syntax, but also the thiscontext binding that createClass can do "for free", so to ensure things still work make sure you're using "fat arrow" notation for this context preserving anonymous functions in onWhatever handlers, such as the onChange we use in the code here:

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.reset();
  }

  reset() {
    // Always set the initial state in its own function, so that
    // you can trivially reset your components at any point.
    this.state = {
      inputValue: ''
    };
  }

  render() {
    return (
      // ...
      <input value={this.state.inputValue} onChange={evt => this.updateInputValue(evt)}/>
      // ...
    );
  },

  updateInputValue(evt) {
    const val = evt.target.value;
    // ...       
    this.setState({
      inputValue: val
    });
  }
});

You may also have seen people use bind in their constructor for all their event handling functions, like this:

constructor(props) {
  super(props);
  this.handler = this.handler.bind(this);
  ...
}

render() {
  return (
    ...
    <element onclick={this.handler}/>
    ...
  );
}

Don't do that.

Almost any time you're using bind, the proverbial "you're doing it wrong" applies. Your class already defines the object prototype, and so already defines the instance context. Don't put bind of top of that; use normal event forwarding instead of duplicating all your function calls in the constructor, because that duplication increases your bug surface, and makes it much harder to trace errors because the problem might be in your constructor instead of where you call your code.

"But then it's constantly making and throwing away functions on rerenders!" and that may be true but you're not going to notice. Nor are your users. If event handler garbage collection is your performance bottleneck, so much has already gone wrong that you need to stop and rethink your design: the reason React works so incredibly well is because it does not update the entire UI, it only updates the parts that change, and in a well designed UI, the time that most of your UI spends not changing drastically outnumbers the time small parts of your UI spend updating.

Function components with hooks (React 16.8+)

As of React 16.8 the function component (i.e. literally just a function that takes some props as argument can be used as if it's an instance of a component class, without ever writing a class) can also be given state, through the use of hooks.

If you don't need full class code, and a single instance function will do, then you can now use the useState hook to get yourself a single state variable, and its update function, which works roughly the same as the above examples, except without the "universal" setState function call and using one dedicated state setter for each value you're working with:

import { useId, useState } from 'react';

function myFunctionalComponentFunction(props) {
  const id = useId();
  const [input, setInput] = useState(props?.value ?? '');
  return (
    <div>
    <label htmlFor={id}>Please specify:</label>
    <input id={id} value={input} onInput={e => setInput(e.target.value)}/>
    </div>
  );
}

Previously the unofficial distinction between classes and function components was "function components don't have state", so we can't hide behind that one anymore: the difference between function components and classes components can be found spread over several pages in the very well-written react documentation (no shortcut one liner explanation to conveniently misinterpret for you!) which you should read so that you know what you're doing and can thus know whether you picked the best (whatever that means for you) solution to program yourself out of a problem you're having.

React 15 and below, using legacy ES5 and createClass

To do things properly, your component has a state value, which is shown via an input field, and we can update it by making that UI element send change events back into the component:

var Component = React.createClass({
  getInitialState: function() {
    return {
      inputValue: ''
    };
  },

  render: function() {
    return (
      //...
      <input value={this.state.inputValue} onChange={this.updateInputValue}/>
      //...
    );
  },

  updateInputValue: function(evt) {
    this.setState({
      inputValue: evt.target.value
    });
  }
});

So we tell React to use the updateInputValue function to handle the user interaction, use setState to schedule the state update, and the fact that render taps into this.state.inputValue means that when it rerenders after updating the state, the user will see the update text based on what they typed.

addendum based on comments

Given that UI inputs represent state values (consider what happens if a user closes their tab midway, and the tab is restored. Should all those values they filled in be restored? If so, that's state). That might make you feel like a large form needs tens or even a hundred input forms, but React is about modeling your UI in a maintainable way: you do not have 100 independent input fields, you have groups of related inputs, so you capture each group in a component and then build up your "master" form as a collection of groups.

MyForm:
  render:
    <PersonalData/>
    <AppPreferences/>
    <ThirdParty/>
     ...

This is also much easier to maintain than a giant single form component. Split up groups into Components with state maintenance, where each component is only responsible for tracking a few input fields at a time.

You may also feel like it's "a hassle" to write out all that code, but that's a false saving: developers-who-are-not-you, including future you, actually benefit greatly from seeing all those inputs hooked up explicitly, because it makes code paths much easier to trace. However, you can always optimize. For instance, you can write a state linker

MyComponent = React.createClass({
  getInitialState() {
    return {
      firstName: this.props.firstName || "",
      lastName: this.props.lastName || "" 
      ...: ...
      ...
    }
  },
  componentWillMount() {
    Object.keys(this.state).forEach(n => {
      let fn = n + 'Changed';
      this[fn] = evt => {
        let update = {};
        update[n] = evt.target.value;
        this.setState(update);
      });
    });
  },
  render: function() {
    return Object.keys(this.state).map(n => {
      <input
        key={n} 
        type="text"
        value={this.state[n]}
        onChange={this[n + 'Changed']}/>
    });
  }
});

try this approach do console.log before of return whenever state will change it will re-render the page. Have a look at this code

import "./styles.css";
import React , {useState , useEffect} from 'react'


export default function App() {
  const [fName, setfName] = useState("");

 // every time state change react will automatically re-render the page
// console.log(fName)
 
function PrintMyState(state){
   console.log(state)
}
 
// calls whenever state will be change , another approach
useEffect( ()=>{ PrintMyState(fName) } , [fName] ) 

 return (

  <input
    type="text"
    placeholder="First Name"
    onChange={(e) => {
     setfName(e.target.value)
    }}
   />
 );
}

sand Box Demo click here

You can use setState and the prevState which is available.

class Counter extends React.Component {
  state = {
    counter: 0
  };
  onChangeHandler = (e) => {
    const currentValue = e.target.value;

    if (currentValue <= -1) {
      this.setState((prevState, props) => {
        return { counter: prevState.counter };
      });
    } else {
      this.setState({
        counter: currentValue
      });
    }
  };

  render() {
    return (
      <div>
        {this.state.counter}
        <input type="text" onBlur={this.onChangeHandler} />
      </div>
    );
  }
}

You're not passing event from input. Change the onChange prop to:

       <input className="ReactSearchBox" name="search"
          placeholder="Search Doctors" 
          onClick={() => {
            this.onProviderListing(this.state.skip,0);
            this.onEnable();
                  }}
          onChange={(e) =>this.onSearchProvider(this.state.skip,0, e)}
        />

onSearchProvider(nSkip,nLimit,e){
  const value = e.target.value; // text box value 
}