Without further ado, the much hyped and heretofore undelivered post about linked lists! Linked lists are one of the most fundamental and important data structures in computer science, and rest assured, if you are interviewing for a position as a programmer, you will be expected to know how to implement them, work with them, and describe some facts about them. But first, why use a linked list?
Okay, so I know I said that in my next post I would cover linked lists and believe me, that will come next week. However, it has since become clear to me that it is pointless to study concepts like algorithms and data structures without first having a thorough grasp of the foundational idea on which they rely: Big O Notation. Today, I will cover Big O and its many applications throughout computer science.
Coming out of boot camp, you will quickly and inevitably come to a few conclusions.
The functions map state to props and map dispatch to props are undoubtedly two of the trickiest and most important concepts for nascent React developers. It is fair to say that you don’t truly “get” using React with the Redux pattern until you fully grasp the concept of mapStateToProps(). Personally, I did not understand the power and simplistic beauty of this function until I had to use in my first React/Redux project - again, and again and again. In fact, it comes up so often in React/Redux, that any aspiring developer should commit to learning its ins, outs, and uses, ASAP. To that end, I offer this quick guide.
Think of mapStateToProps() as a bridge between components. Whenever you need a piece of state within a component that it is not native to that component, mapStateToProps()! This way, the component can remain stateless, as is the preference in React, but has access to any properties from the state that it may need. As an example, in my recent project, I made the user id a piece of the state, effectively managing the current session from the front end in this way. However, when creating resources via forms from the client, it became necessary to access this user id, since it was required by the back end to be sent with the form data. So what did I do? Inside my input components, I mapped state to props. This gave me access to the user id I needed, while leaving the components without control of any state.
The bottom line is, whenever you are in a a bind early on in your React career, and cannot figure out how to gain access to a property that you need, there is a good chance the answer lies in mapping state to props. Learn this function, practice it, understand its use cases, and you will greatly expedite your learning curve as a React developer.
And without further ado, my final project and my time as a Flatiron student are in the bag! I have officially learned enough, toiled and fiddled enough, and spent enough late nights and early mornings contemplating life and code to be considered an employable web developer. Self reflection (mostly) aside, I am very proud, humbled, and most of all excited to have reached this point. This project was far from easy, and I have definitely learned more from it than any prior project or lesson. I now feel that I have a solid understanding of what developing a functional application, from inception to fruiton, is truly like. For a time in the development process, it seemed all I could do was hit roadblock after roadblock, insurmountable obstacle after insurmountable obstacle, and I genuinely doubted that I would be able to complete this project in any reasonable way. However, now that I stand triumphant and look back on it, I see and truly understand that this all part of the process. Coding is in many ways a test of willpower, and holding strong reaps infinite rewards. So, before I bore you to death with my victorious musings, here is a bit about my React/Redux final project. My application is essentially a simple accounting database. A user can input their financial information, including any bank accounts, credit cards, investments, notable assets, and outstanding loans, and receive an up to date view of their financial picture and net worth. All of the aforementioned components correspond to a model on the Rails backend, and to a container with an input form, a display page, and some actions and reducers on the client side. Queries are made to the server via fetch, and are broadly defined in three categories: user actions, posting of new resources, and retrieval of existing resources. Of the three, the user actions were by far the most difficult. Before knowing entirely what I was doing, I naively placed Devise on the back end to aid in my authentication needs. This necessitated various workarounds and schemes to ensure that I could sign a user up and log a user in the front end, and persist this user’s data. If I had this to do over, I would certainly forego Devise in a full stack application, and implement a much simpler authentication scheme. Next, there were the POST actions. From the homepage, a user can navigate to the forms for adding any of the resources that pertain to his/her financial picture. Again, hoops had to be jumped through to allow posting to the Rails API, particularly because everything tends to be just a bit more complicated in AWS Cloud9, but this exercise seemed simple after the nightmare of user authentication. Finally, there were the comparatively simple GET requests to the server side, used to retrieve a user’s financial information and save it to the state. If the whole project had gone as smoothly as this part… but I digress. Ultimately, the challenges faced in this project have made me a better and far more confident developer, and I am genuinely excited for what the future holds.