My First JS Meetup
As part of my ongoing effort to become more involved in the web development community, I attended my first meetup this evening. It was hosted by the South Bay & OC Chapter of JavaScriptLA. Tonight, web dev bootcamp (LearningFuze) instructor Scott Bowler gave a talk on Best Practices Within React.
Going into it, I wasn’t sure what to expect. I’d never been to any official gathering of developers since graduating from UCI, and on top of that I’m not even particularly comfotable with React yet. I started learning it a few months ago, but decided to put a hold on that and take a step back while I worked on mastering vanilla JavaScript. In preparation for this meetup I fired up a few more React tutorials again, and I found them a lot more intuitive than the last time I tried.
It turned out that the meetup really just felt like a more informal college lecture, so it wasn’t nearly as uncomfortable as I’d feared. Even though I’m not a React veteran, I was still able to follow along with the speaker’s advice. I felt like I got a lot out of the talk, and it was nice to learn as part of a group again after being an academic hermit for the past few months. Several mandatory Windows updates (and my lack of foresight in not bringing my charger) drained my laptop’s battery while I waited for the talk to start, so I ended up taking notes by hand. Here are the main points I got out of the meetup, broken down into just the essentials:
File Organization
- In component folders, avoid generic file names like “index.js”. These can get confusing if your project has a lot of different components.
- The exact file structure you decide on doesn’t matter as much as consistency, but there are things to keep in mind
- Your file structure needs to account for scalability
- Try to avoid excessive nesting. This can make imports overly convoluted.
When to Use Class Components
- You only need to use class components if you’re working with state or lifecycle. Otherwise you can use functional components, which are less expensive.
Refactoring
- Writing succinct code is good, but not if it makes your code unreadable
Index as Key
- It can be tempting to use index as component key, but this can cause some nasty bugs
- React may not recognize a state change if the index has not changed, and so will not update the virtual DOM
- If you’re making dummy date, just make up some unique numerical IDs (001, 002, 003, etc.)
- If you’re working with an actual database, then you have a column of unique IDs to draw from already
”<div>
-itis”
- A lot of React code you see has pointless divs that don’t serve a functional purpose. Try to avoid this!
- Not only do they clutter up the HTML generated by JSX, they can also break up proper HTML hierarchy (such as nesting a
<div>
as the immediate child of a<ul>
)
- Not only do they clutter up the HTML generated by JSX, they can also break up proper HTML hierarchy (such as nesting a
Component Crash Testing
- At the bare minmum, your components should have crash testing
- Can save time instead of having to hunt for broken components
- You should have additional testing on top of this to verify behavior, not just that it doesn’t crash
Unnecessary Data in State
- Any time the state changes, React will re-render
- If your data update will never be displayed to the user, it doesn’t need to be in state – you’ll cause extra renders and slow everything down
This meetup was definitely a positive experience. I’m glad my first one was during a talk that was relatively easy to follow along with, and it was encouraging being around other people trying to learn more in their free time. I’m going to be keeping my eye out for more interesting meetups in the future!