Pass a Callback as Props - input question

Link to challenge

I’m wondering why it is that we bother passing a prop called input to the GetInput component, when the app doesn’t seem to need it in order to function correctly. Is it just a case of demonstrating something about the flow of information from the parent?

The way I understand the code is that the value attribute of an input element is whatever you happen to type in the box , so in this case we are using a long-winded method of (re)assigning that value based on the state in the parent component, but that doesn’t actually serve any functional purpose in this particular case.

@MarbledMinorMoth Yeah that right.

Basically, React components are pieces of reusable code, like functions. You could probably write a whole piece of software in one function or React component, but it won’t be pretty and will be hard to read and understand. To have more readable and usable code, you make multiple React components and pass props (like having multiple functions and passing in parameters).

So , for example, the ‘Drum Machine’ project in the ‘Front End Libraries’ section. It needs something like 10 clickable elements (somewhere around there). You can definitely create all those 10 buttons that need to be given unique attributes in the main ‘App’ component and enter those unique attributes in manually:

<button id="1">Im button 1</button>
<button id="2">Im button 2</button>
<button id="3">Im button 3</button>
<button id="4">Im button 4</button>
<!-- ...and so on -->

OR you can create one button React component, call that component in the main ‘App’ component coupled with a JavaScript iterating function like ‘for()’ or ‘map()’ , and pass in props:

//this is a stateless React component:
const clickableElement = (props)  => (
  <button id={}>Im button {}</button>

The reason is described at the bottom of the challenge description. Whenever you have inputs in your React components, they will be “controlled inputs”. The only place that decides what should be in that input field is in state. It will keep track of new inputs, and pass the current value of the input down to the input component. That’s what’s meant with “state is the single source of truth”.

Welcome, MarbledMinorMoth.

Just to add: As far as I am aware, with HTMLElements like input, they have special attributes like value which hold the element’s state. So, in plain HTML you can get the value of the input like you would any other object inputElement.value.

Now, React revolves around state. State is an integral part of React elements (components). So, an undesirable situation occurs when an element’s state is not the same as its parent component’s state. How do you keep the two in sync… By, storing the input as state, and only updating the value when the state updates.

Some sudo-code:

class MyComponent extends React.Component {
  constructor() {
    this.state = { value: 'initial value' };

  onElementValueChange() {
    // Update component state to remain
    // in sync with element state, and vice-a-versa
  render() {
    return (
        <input onChange={onElementValueChange} value={this.state.value} />

Hope this helps

Thanks for all the responses.

I think my query remains around this idea of there being a possibility for the value held in the parent component’s state to be different from the value of the input element itself. After all, the only reason there is anything in the parent component’s state is because it was entered in the input element - which shows that the flow of information isn’t strictly top-down. If this wasn’t the case the logic of the code would be circular.

If I understand, the main reasons for using controlled forms would be for the purposes of being able to manipulate the input data in real time instead of having to wait for the user to finish and submit?

Couldn’t synchronisation issues be avoided by directly referencing the input value in the RenderInput component instead? Or is the setState() method necessary because it updates the UI and can therefore show the changes to input as they are made?

Yes, this is definitely the advantage of React’s form control.

Most of everything we are discussing is just a direct consequence of React’s virtual DOM.

I am not sure what you mean by this, as the input element is not inside the RenderInput component…

Yes, again, all related to React’s internal handling of its virtual DOM, and how state is an important part of components.

You are welcome to ask more questions here, but my knowledge on the matter is not much more than this, and is mostly my interpretation of it anyway. So, I would recommend going through specific parts of the official React docs, if you would like to know more.

I will always recommend this video, though:
Deconstructing React || Tejas Kumar - YouTube

Hope this helps