Is it pronounced route or route? I think it’s the first one.
This week introduced the React Router. And although I’ve worked a little with other routers through APIs this feels like another thing with a familiar feel. The React Router allows for the development of single page dynamic sites. It creates routes that can be linked like different pages and return a new component into the DOM. With a thorough enough router setup, a whole site can be developed and deployed through a single React page.
JavaScript hoisting is a topic that’s come up several times before and I see it more and more in my code. JavaScript will allow the calling of a variable before it’s declaration in many cases. When it runs through the code, it will find that variable declaration and move, or hoist, it to the top. So when that variable gets called, it’s already a top level variable with a declared value. Without hoisting like this, it wouldn’t know the value or even the existence of this variable when it’s called on since the declaration happens afterwards.
setState() is an asynchronous React function like I’ve spoken of before. And it needs to be. The process of setting a state can take various amounts of time to complete. It could be as simple as toggling a boolean. Or it could be a fetch request that may take an unknown amount of time to complete. Or anything in-between. Because of this, it can’t be a synchronous function. If it takes a long time to get back the new state, it will stall out or even crash the app. Being asynchronous allows it to take the time it needs to return the data just like a promise. Then when it has its results, the setState() jumps into the event queue for it’s turn in the call stack.
Dirty checking is a new concept for me. I haven’t heard of it before now. And from what I can tell, it’s part of an older process for React. The virtual DOM seems to be the more modern approach to state updates and renders. The virtual DOM watches the state and will re-render the appropriate components if there is a change. Dirty checking seems to be where the states must be checked at intervals to look for any changes. And then re-render if there are. And while the virtual DOM sounds like it would be a little more resource heavy to run, it is much more efficient and faster to respond.
A React Component and a Pure Component are almost the same thing. The biggest difference is that a pure component has the shouldComponentUpdate() lifecyle method built into it. Plus is will only do a shallow comparison of the state and props to look for a change. This means that it will check the previous props and state comparted the the next by iterating over the keys of the objects. It returns true when the values are not strictly equal. But this means that data upstream can update or change without updating the keys and it won’t detect the change. Nothing with re-render. This is where a normal component will be a better fit. It does a deeper comparison and can detect the change upstream as something to watch for.
In React, a Higher Order Component is very similar to the concept of a higher order function in JavaScript. It’s an advanced element for reusing logic in React Components. They are used most in design components that have a shared behavior. A common one to use for example is one from class this week. react-redux uses the connect(mapStateToProps)(component) component to help create it’s redux router and takes another component as its argument.
So far our in class use of checkAuth() has mostly been using dummy data that we save in our code. It checks that the data is there and returns true. But in a real world situation, that’s not a very secure way to store usernames and passwords. Most likely, implementing a service like Auth0 or something similar would be a better option. Then names and passwords can be stored securely and checkAuth() will be able to request a login token to confirm that the login was correct. Without a token being return, checkAuth() won’t return true and no login will happen until it does. I haven’t created something like this yet with React. But this is how I think it should go.
React and Redux has been more challenging than I would prefer. It’s not that the syntax is difficult or that the concepts are hard to follow. It’s just a new way to wrap my head around designing and building an app or site. It takes it a little bit away from a more visual process to a building block kind of structure. It also take a little bit from everything I learned so far and tweaks it just enough to make it feel different.
