Going into my final project was pretty nerve wracking to say the least. All the hard work and newfound knowledge I have acquired over the past 5 months all come down to this project. This would be the project that pushes me through gradutation and ultimately into the Software Engineering workforce. However, with the idea of adding a framework and, essentially, ‘rhyme and reason’ to the JavaScript code we learned in the previous section reassured me throughout the project and utimately connected all of the dots in my head.
Being able to provide a quick, seamless, and efficient webpage to my user was by far the most rewarding piece of this section. As studies have shown, a user will navigate themselves to another webpage if the one they are trying to access does not load within 3-5 seconds. Therefore, it is extremely important to have an application that works quickly and grabs the users attention to keep them on the page. This was all made possible when introduced to Client Side Routing. Client Side routing has enabled us to avoid having to query our backend code in order to retrieve the data the user is needing access to. CSR enables the client side code to independently handle the routing, fetching, and displaying of data in the browser and eliminateing the need for the user to wait for a round trip server call in order to see the information they have requested. With this being said, there are a few things to keep in consideration as we build out our Client Side Routing. The most important being the load time for the first page of our application. Since the application is loading the CSS and get request for the first page, this can take some time, therefore if we have a large application with a lot of data it could take a while to render and we may want to look at alternative approches to keep our users attention while this happens. (spinning/loading icon perhaps)
The most difficult piece of material in this section was understanding the way State is manipulated and maintained, as well as the benefits and appropriate times to use state over props. After some digging I was able to clearly separate the two with the following logic. When dealing with any type of data, we can separate it into two categories: Data that will change, and data that will always remain the same. Props are primarily used for data that will never need to change. In order for us to update a components prop, the prop’s parent element would have to send it new props, and the data would then recreate itself, causing us to lose history of that objects transformation. Whenever we are dealing with data that we know will change throughout its lifecycle, we should look to use State. State will enable us to update a component without having to figure out how to pass down new props from the components parent. But wait, how does state do that? In order for state to update a component, we first need to set the initial state in the components constructor method, afterwhich we will have access to a method provided by the React.Component class called ‘setState()’. Essentially, setState() accepts an argument of ‘instructions’ letting the component know how the components state needs to be updated. This update also occurs in an asynchronus manner meaning that instructions to update the state would need to complete in full before setState() updates the state of that component.
As I finish up this Software Engineering course, I am becomming more and more excited to reenter the workforce and be apart of a team that builds amazing products. I thrive in a team environment and believe I can effectively contribute to the development of an application with the skills and knowledge I have learned throughout this course. As always I would not be here today without the immense support of my friends, family and classmates. I would like to thank them for all of the help and encouragement they have provided me throughout my time at Flatiron and into the future of my career as a Software Engineer.