I'm learning the ReactJS framework. I'm not clear on below aspect.
When a user enters some value in a form cell, does it modify in actual DOM? or just updates directly first in Virtual DOM?
Thanks.
Neither, React has a unidirectional binding, meaning that when you change the state (using this.setState({...})), render() is called again. This updates the virtual DOM and then updates the actual DOM.
If a user enters input, nothing will happen unless you setup something to change the state on user input (for example, adding onChange()). The onChange function will then need to update the state with the new value.
When you enter a value in form cell and there is no input handler for that input field. The actual DOM is getting modified as you are entering the value in a cell and that value will be persisted in the form cell.
But we usually don't do this, instead we will have a onChange handler in our component which will take the new value and render back the input cell using render method. After render is called, virtual DOM is first updated and then react does its magic of diffing to find out whether the real DOM needs to be updated or not.
Related
I have a component with about 16 input fields. The component itself is quite complex. The problem is that every time it updates the state of the form on input change it triggers a re-render. Rendering that component is a bit expensive, there is a short delay noticeable when you type a character inside an input.
What is best practice in such a case?
Maybe I should update the state only when the user submits the form?
if you don't want to use any other library that manages form state,
you can move the form to another component, in this case only the child component that conains your form will rerender on changing inputs values, not the parent component, and pass to it the function that handles submit in props to trigger changes in the parent component when you submit the form
I have a question that why we need to use onchange event in react and set the state on every change event and why we cannot change the state of all the input fields of the form on submit button?
When we use onChange in an input field, it performs all the inbetween steps to set the state on every change event, so why don't we use event.target to store all the states on submit or it is not possible?
you can control the form with state and then you will need to change the state whenever user changes the input by handling onChange method and updating the state, because the input always shows the state value and not whatever user types.
if you want to reset your input fields after submit without using state you have to get the refs of your input (by using useRef or createRef) and change the value property of input imperative after submission.
I create 2 Text Boxes one with hook and the another one with the old style, now in Hook mode when the user input change the textbox value the whole page rendered, but with old style there only the text-box rendered not the whole page, if you have the complex page with many objects like (Data Table, form, buttons, inputs, etc..) the single change on one of these components forced to re-render everything and it decease performance, for example typing in the text-box take time to effect on page and the delay time is more than user typing speed.
the one workaround solution is using the callbacks and useMem but if the page is complex(lots of objects as described, and all of these objects has many properties the callback and useMem is very very complicated to handle single object property.
SandBox Example
This is exactly how react hooks should work. what will cause a rerender in react? two things:
change in props
change in hooks or say in a better way hooks state
in the second case, the useInput state is changing so that causes a rerender and it's absolutely normal behavior. I think using custom hook in that way is not a good practice.
I recommend reading this article for more information on react rendering: https://www.codebeast.dev/usestate-vs-useref-re-render-or-not/
I'm using Semantic-React and I have component-filter which consists of checkbox groups. Every checkbox has id and I must pass them in order to filter the results.First idea was to perform method which would be called after checkbox onCLick(which would pass checkbox id). And in this method set in state an object and after every checkbox click change it. I remember, that in Jquery exists $('form').serialize() which everytime checks form elements and gets checked values automaticaly. Exists something like this in react, or semantic-ui react? I would be simplier to use such method than to create and control object in state
You should use "controlled components":
Filter component should keep a set of checked ids as part of state.
Checkbox checked property should be set to true if the set contains box id (and to false otherwise) in Filter component render.
Checkbox onChange should be handled by filter component and modify state.
Filter can access it's state handling checkbox onChange or button "Apply" onClick (or any other event handled by Filter component).
Be careful: setState is an async function and directly reading other component state can lead to data race, so state must be read after proper event fired by React. Also there are a bunch of state-keepers like Redux.
It is described in official docs here: https://reactjs.org/docs/forms.html
This is from a couple React tutorials that I'm currently reading:
the State drives what the guys at Facebook call one-way reactive data
flow, meaning that our UI will react to every change of state.
and
Typically UI’s have lots of state which makes managing state
difficult. By re-rendering the virtual DOM every time any state change
occurs, React makes it easier to think about what state your
application is in. The process looks something like this, Signal
to notify our app some data has changed→ Re-render virtual DOM ->
Diff previous virtual DOM with new virtual DOM -> Only update real DOM
with necessary changes.
The first quote seems to suggest that the data flow goes from React to the UI. But the second quote seems to suggest that it goes from the DOM to React which then re-renders the virtual DOM and the diff process than repaints the real DOM. This sounds a lot like Angular's two-way data binding.
Is this true? What am I missing? Is one-way reactive data flow just another name for Angular's two-way data binding?
I think it's necessary to make a distinction between React and Flux, both of which implement a uni-directional data flow. I'll only touch on React here.
In Angular a change to the DOM will directly mutate the value of bound scope variables in your controller thanks to angular's two-way data binding and the digest loop. It is two way because, of course, any change in your controller is also directly reflected in the view attached to it.
Think of Angular as Controller <--> View
In React a component always renders its DOM based on its props and internal state. A React component can listen to event being fired in the DOM it rendered, which might sound a bit like two-way data flow on the face of it but there is an important difference: An event fired on the DOM does not directly update the internal state of the component. The component must listen to the event and then explicitly update the component with the new state. This change of state then triggers the DOM to be re-rendered (if it needs to). In this way the components props and state are the single source of truth and always drive the DOM output. Of course changes in the DOM can affect the component but it is done in an indirect manner.
Think of React as Component State --> DOM --> New Component State --> New DOM
Angular's two way of binding's essence is that the view is bound both to the model and the user's input.
With React, the view is bound only to the state and a user's input cannot directly change the view, but triggers the component's own methods to update its state and Reacts job is to rerender the view so it reflects the state.
The flow here is:
Component
state-> virtual DOM -> DOM
This is always the flow, whether its initial render or second render.
The quoted bit is:state->virtual DOM -> DOM
newStateDifferentFromOldState -> virtual DOM
diff virtual DOM from 1 with virtual DOM from 2
Only update the elements of the DOM that are the net difference of performing 3.
e.g. 1->2->3->4, repeat in this order from 2 (2->3->4->2->3->4...so on)
This is in no way related to the concept of two way data binding.