Using STATE to ensure the DOM and Database contain the same information.
As you make changes to the database with POST and PATCH requests, use a callback function to update STATE to ensure your data is up to date.
The display of information in your application can be achieved most easily by manipulating information and displaying it via the DOM. The challenge with this is that in most circumstances, the information is not stored on a refresh of the page. To address this, using a separate database to store the information ensures that any chances can circumvent the refresh reset.
The thing to consider when evaluating these ideas is that both the information on the DOM and the Database should match. The protocols for updating each of these independently, do not ensure that both locations contain the same information.
The connecting element that will support consistent data display and storage is updating a STATE variable in the PATCH/POST request via a callback function passed as a prop to the active component.
Updating Information in the Database
With an application that needs to keep information the same between visits, a backend database is required. Whether you are adding new content or updating current content, the use of POST or PATCH requests respectively, ensure that changes made are stored for future use. The basics for setting this up are adding an event listener to an input mechanism, such as a button or check box, and a function that accesses the database and performs the appropriate function.
In the example below, the handleSubmit function creates a new project object and adds it to the project database.
Creating the STATE variable
At this point, the data is updated in the database, but you would notice that the data displayed in the DOM is not changing. This is because while the data is in the database, there is nothing that triggers the display the new or updated information. This is where a STATE variable can assist in updating the DOM.
To begin this process, you need a STATE variable that stores the information taken from the database.
As you can see in the code above, the useEffect( ) hook executes an initial PULL request. The data from the request is then set as the value to that STATE variable called “project,” which is then usable in other components when passed as a prop.
Updating the Information on the DOM
Now that we have a place to store the updated information in the DOM and initial values, we need to create a function that can be used in the POST/PATCH request to re-set the value of the STATE variable to the new information.
*REMEMBER that the POST/PATCH request is already updating the database.
**ALSO REMEMBER to consider where the STATE value should reside. If your state is only needed in that component, there is no need to pass it as a prop to a child. However, if your STATE resides is a parent component, remember that it needs to be passed as a callback from the parent component to the child as a prop, which will be the case in the example used.
In the code below, a function was created to take in a new project as an argument, add it to the previous list of projects stored in the STATE variable “projects” and then assign that new list to the STATE variable “projects” using the setProjects function.
Based on the structure of the example application, this function needed to be passed as a prop to the child component where the new project was created.
Once the function is pulled in as a prop, it can be used to update information in the DOM, by changing the STATE variable stored in the parent component.
As a part of the .then statement that uses the returned data from the POST request, we can use the callback function to pass this new data into the addNewProject(newProject) function (created in the parent component) to update the information stored in STATE.
The value of the use of the callback function WITHIN the FETCH request is that the data being passed to the database is the same value being passed into the callback function which is stored in the STATE variable that provides data to be displayed on the DOM.
Summary and Conclusions
As we saw in the sequence above, keeping the database and DOM data in line ensures that the front end information always matches the back end data. While updating the variables in the DOM would appear to allow the app to work as intended, the lack of storage on the back end means that all data would be lost when closed or refreshed.
Thus, the inclusion of the DOM update AND the CRUD protocols makes sure that all data manipulated would be maintained after a refresh or reopening of the application.
Where Do We Go From Here? is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.