I think every developer can agree…whiteboarding is nerve-wracking. Standing in front of executives or senior level engineers with a given algorithm, a whiteboard and a marker, your first instinct is usually to whip out a solution to a memorized pattern in specific language. Having a couple of whiteboarding experiences now, I can say that the right way to handle whiteboarding is similar to how you would go about solving any problem.
I love building full-stack apps using rails api and react for the front end. The two frameworks were seemingly made for each other and it’s very easy to manipulate JSON with both tools, making transfering data less of a headache. Of course, without the right organization, it’s easy to get messy…fast. Learning and mastering common best practices has made developing not only easier but more fun throughout the process. I thought I’d provide a few little tricks I’ve picked up along the way that will provide ease to work flow.
My curiosity about React components updating the UI without manipulating the real DOM was something I found peculiar…how and why? I mean, if that’s not magic, I don’t know what is. As a user, I can manipulate and interact with the browser, watch the GUI change and transform right before my eyes, all without actually changing the browser’s DOM or even making a call to an API. My understanding before doing some minor digging was that once state was updated in React, the virtual DOM updated the page starting with the root node of the document’s tree and then the user could see and interact with the updated components rendered on the screen. This was quite a thumbnail sketch understanding, of course. Of course this is just part of a well implemented and efficient algorithm known as diffing.
This tutorial is aimed at the intermediate Rails coder that wants a detailed, yet loose enough to make their own, instruction manual. Hopefully by the end of this tutorial, you’ll have a shiny new app to show off and have learned something new or brushed up on old skills. This tutorial also assumes you have basic Rails knowledge, but a beginner can easily follow along with an expected learning curve and some independent research on certain topics.
At the most basic level, fetch is essentially making an HTTP request that relies on a promise, which is much like a callback. A promise is a placeholder object for the eventual result value of our fetch method or reason for error will manifest. Now, what happens next is dependent on the execution context of your program. Normally, there are two different functions you can call, then() or catch() depending on the state of fetch. If it’s fulfilled, then() is chained to handle any asynch actions that need to happen with the data object fetched from the API. That then returns another promise, which is handled by synch or asynch actions once again.