- I like to think of frameworks as the overall blueprint being used to construct a website or application. A framework in itself is basically a collection of libraries that calls the code, whereas a library can be called within the code. The video by Hitesh Choudhary explained it really well where we can think of frameworks more as a school where there is a clearly defined set of rules and processes, whereas a library can be thought of more as your home where the rule structure is a little bit more loosely based and you can invoke these rules at your own will. In previous modules we have used frameworks and libraries in our testing suites, where mocha has been the testing framework being used and chai is the particular testing library.
- According to our readings, the biggest benefit of using a framework is that it enables us to keep the ui in sync with the internal state (current values or status of data the being manipulated). By using a framework we are able to keep the interface dynamic and consitently update based on the what the current state of the data is. By using the pre-written batches of code in the form of frameworks and libraries, we are able to effeciently update the DOM through the process of reconciliation (creating a virutal DOM, compare the virtual with the currently existing DOM, and perform necessary changes in differences). In order to do this using vanilla javascript, the codebase itself would be very complex and inefficient. I can understand why we did not use many frameworks and libraries in modules 1 and 2 so that we are able to better understand exactly what is going on behind the scenes, instead of simply importing these as shortcuts without necessarily understanding exactly what they do.
- In the article by Tyler McGinnis his visual representation of components was incredibly helpful in understanding exactly what a component is. The definition used of a component was that it is the core building block while using React, it is a combination of javascript, HTML, CSS, and internal data unique to the component itself. Visually, each component could be seen as seperate sections or divs within HTML that define what they are on the application (sidebar, info card, nav bar, etc.). It is useful to have multiple components so that you can be more specific in what part of the application you plan on updating. For example, if you have one component that encompasses the entire body of the website, it would be more effecient to have a child component for a specific area within the body that you plan on updating with specific methods that only pertain to that one area. While creating components using React, I am going to keep in mind the ideas of encapsulation and modularity so that each component is not reliant on other components for data manipulation and updating on the DOM.
- I am still a little fuzzy on exactly what JSX is, but my current understanding of JSX is that it allows us to write HTML like syntax in order to produce javascript elements and objects. Such as declaring a variable of 'name' equal to an a string surrounded by p tags. This will be used to properly update elements within the DOM with the correctly formatted HTML. React is then able to take these JS elements and objects and form a virtual DOM, which is an updated representation of the actual DOM object.
- Props, or properties, is the data passed down to the child component from its respective parent component. Within the codebase, these props should be immutible as they are consistently shared traits among their defined components. Because of this, the child component should not be able to change the actual information the prop contains.
- State in the context of using React refers to the internal data in the form of an object of a component. When updating components on the UI using React, we are effectively updating what the state of that component is. I like to think of the state as the current status of information currently displayed to the user. As the user interacts with the page, and manipulates the data, they will then be changing the state of the page itself. State will differ from props as it is data that can be changed, whereas props cannot be changed.
- 'Data down, actions up' refers to the uni-directional flow of data passed from one component to another. Earlier, when I was describing what a prop is, I had mentioned that a prop is basically the DATA that was passed DOWN from the parent component to the child component. User interactions will be handled within the child component in a variety of ways (onClick, onSubmit, onChange), once the action has taken place, the child component then needs to notify the parent of the respective changes.