Reactions to React
I initially was taken by the freedom and power behind Javascript in itself. However with that freedom and power, it becomes very easy for your code to clutter and look extremely messy. A working frontend that manipulates the DOM exactly as intended can still work with a very unorganized layout, without any structure at all, and most likely only understandable to whomever wrote it. But as Martin Fowler once said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand”. As our cohort continued to learn about the tools available to frontend programming, we were introduced to a JavaScript library known as React.
React was very intimidating at first, but in reality, so is everything else unfamiliar and new to us. As I continued to learn about its use and implementation, it seems like the ultimate solution to all the ways vanilla JS can be problematic or inefficient. This particularly shines through the fact that React is declarative, as views are designed for each state of an application. The DOM is only re-rendered when a particular state changes and when using React correctly, it can show you all the visual changes right then and there only when something actually changes. As amazing as it is, there’s still a best practice to follow as with anything available to developers and there were some design patterns that I needed to adopt and understand so I could use React to its fullest.
The most crucial part of understanding React is understanding that it’s component-based. When structuring an application using components, it’s a huge aid in separation of concerns meaning code which serves a particular purpose is distinctly grouped with alike code only relevant to the outcome looking to be achieved. With plain old JavaScript, it was easier to just maintain scope have so much code all in one place but never knowing where the problem was when faced with a bug. It’s fair to say I’ve since then better understood JS while learning how to use React. With well-separated concerns, your code is less repetitive and more reusable and this showed through React’s component-based design. Components could be configured as a container or presentational component. Container components focus more on logic where presentational components, as the name implies focuses on how things look. However, React doesn’t tell you which is which as it’s more of a convention to follow. Usually as you familiarize yourself with React, you find that container components are more stateful and written as functional components whereas presentational components are stateless. After understanding React as a component-based library, I had to better grasp the concept and stop being afraid to separate my code into different files. I eventually came to learn that sometimes a component could be only a matter of just a few lines and that was totally fine if it did as it was supposed to included everything relevant towards what it was supposed to be doing. I just asked myself if I were looking at this layout as someone else, is everything located where I’d expect to find it? If yes, I could comfortably move on.
Another concept I came to grasp was, despite its physical similarity to HTML, JSX elements are still very different. When using JavaScript, it was a routine of writing functions, selecting elements of interest in the document’s body and storing them as variables, passing variables to our functions, appending nodes to new child elements and adding them to the DOM. Everything seemed very literal in each step that took place. However with React, I had to stop looking at JSX elements in comparison to what I knew them “elements” to be as they referenced something very specific. Instead, React combines JavaScript and HTML, making JSX elements more representational of elements yet to be defined. It’s intentionally left vague as it gives for more flexibility and, more importantly, reusability to the code.
In the end, how the code is structured will always be up to the programmer. However, I’ve learned that sometimes challenging a lot of ‘what works’ for sake of new practices and better habits is just like the first dive in the water; cold at first but enjoyable when you’re in. When learning new frameworks that provide new methods and new conventions to follow, it also provides a piece knowledge that can be carried around regardless of syntax or what’s being developed. React strongly emphasizes separation of concerns to an extent that helps me better-pinpoint where certain code belongs. It also taught me how abstraction can exist in multiple ways, where in this case a whole file could simply be 5 lines of code and that absolutely fine as long as those few lines did everything they’re supposed to and aren’t repeated elsewhere.
