In my last blog post, I talked about why I’m taking a deep dive into web fundamentals. Through both academic and professional experience, I found it very easy to succumb to the pitfalls of following tutorials and relying on StackOverflow to get things working. You can check it out here.
My ultimate goal is to be a more empowered developer who codes with #a11y and purposeful design in mind. I’ll discuss the misconceptions I had going in at the beginning of this journey (back in March), and what I now understand.
Misconception: Relationships between components in React are the same as the hierarchical relationships between classes in Java.
Not at all. In fact, there are few instances in which classical inheritance is the solution. I mistakenly equated the terms parent and child components with parent and child classes. The downside to classical inheritance is the tight coupling formed between classes in the name of code reusability. What helped me realize the downside was the gorilla banana problem.
“What you wanted was a banana, what you got was a gorilla holding the banana, and the entire jungle.”
So that roughly translates to children inheriting behavior from the parents that they might not necessarily need. Refactoring code into small units of functionality or object composition makes WAY more sense than inheritance. A component should theoretically only be responsible for one thing. If the responsibilities grow, it might be time to refactor into subcomponents. Components are nested within each other, hence the “composition”. That’s how props in React are passed from component to component.
📖 Composition vs Inheritance
CSS is NOT as easy as it seems. I remember now the amount of times I would try to get a side project going and think I would achieve the most beautiful UIs by thoughtlessly copy pasting CSS snippets from StackOverflow or by relying on CSS selectors. Strangely enough, those code snippets only worked about 3 out of 10 times. I would get ragequit the other 7 out of 10 times, orphaning another side project in the process. This time around, I used the handy-dandy Dev Tools to debug CSS, and I noticed my CSS styles were being overridden by something called User-Agent Stylesheet. My first impression was who is User-Agent and is this proof that the FBI is really monitoring our every move? Kidding, of course. For the first time, I understood the CSS Cascade algorithm, and how the 3 potential origins of CSS rules (User-Agent, User, and Author) are pitted against each other and the victor determines the style of the web page. Well, not quite. The origin is the most weighted factor into the outcome of which styles are eventually rendered.
📖 How CSS works: Understanding the cascade
Bear in mind, I identified these two concepts that I should've focused on prior to starting my job as a front-end developer on enterprise IoT applications. On a story by story basis, I contributed to the codebase with relative ease but when tasked with a feature that touched many views in an application, I struggled with putting the pieces together and why our code was structured the way it was. Mentally, I was projecting Java concepts onto a React application, and underestimating CSS.
Moving forward, I want to tackle the following:
⚛️ Props vs. state
⚛️ Redux for state management
⚛️ CSS specificity
⚛️ DOM concepts
⚛️ Pure functions
⚛️ React hooks
Thanks for tuning in! Please let me know if there's anything I should add to my list of what to focus on :)