React Native Workshop Day: Taught by Kadi Kraman, Hosted by Frontend Masters

3/6/20 — React Native Workshop Day

Today was different and different was good. I woke up at 7:10 — a tad earlier than usual — and I took the bus to Minneapolis so I would avoid downtown parking and driving in rush hour. Unavoidable, though, was the frigid winter air; but I couldn’t complain too much, as the sky was overflowing with beautiful sun, and the excitement of the atypical day kept my spirits up high.

Somehow, I slept okay and felt well-rested enough, and I say somehow, because, this rarity never seems to happen when I’m eagerly anticipating the next day. Even as an adult, I’m still inflicted by the early Christmas morning jitters you get as a kid.

I think this rare occurrence occurred because I felt prepared for the workshop. Once I got word I was invited to attend, I set up my React Native environment the first chance I got, and went through Net Ninja’s React Native video tutorial series soon after that.

Before the big day, I coded through video 32 of 35 while taking notes of what I learned throughout; so after making it that far, I felt comfortable enough with React Native where I wouldn’t feel like an imposter going into the workshop… Or so I thought…

Kidding, kidding, kidding. I didn’t actually feel like an imposter, but I did feel like a noobie being surrounded by a bunch of legitimate pros. Pros who, unlike me, are actually employed within the industry and have more to their name than just a Yahtzee game coded in vanilla React. (This will change in the future, let me tell ya.)

The guy to my left, an obviously-seasoned vet named Mark, had no problem whizzing through all of Kadi’s lessons. It was easy to see the difference between him and I. I needed to slow down and take my time to dissect the later lessons, and he needed almost no time at all. He had them complete within the allotted 15 minutes, where I would have needed an hour or two; with many back-and-forths between my code editor, documentation, and a mind chatting with itself. Let’s just say, jealousy was oozing out of me throughout.

I shouldn’t sell myself short, though. I only used Hooks and Navigation a few times beforehand, and I haven’t looked at code on an everyday basis for handfuls of years. (Not yet, at least.) If I had, I know it would come quickly to me too. I too would be able to visualize the solutions in my head. When I devote my mind to something on a consistent basis, day-in and day-out, I end up becoming very skilled at it and start to see it in my sleep. It just takes time, effort, and practice. I’m not there yet, but I know I will be someday. I just need the right gig to bring me to that level.

But that’s enough about me for now. Let’s direct our attention to a few others more deserving of it.

To those more deserving of it

Kudos must be given to Frontend Masters and its CEO / event coordinator, Marc Grabanski. You don’t expect CEO’s to be super approachable and down-to-earth, but those are qualities Marc exudes. He’s a class act, and I found it impressive that he didn’t delegate communication responsibilities. The e-mails and coordination were all him, and he was also in attendance throughout the entire thing. He is a hands-on CEO, and that is something I admire and respect. Plus, the entire workshop was extremely well done. Professional from top to bottom. This, of course, could only be accomplished if the instructor were a professional herself…

And boy was she ever. Kadi Kraman is a true professional. Not only was her live-coding impeccable, but she didn’t miss a beat throughout the entire recorded session. Even when a tricky question was presented, or she had to stop-then-restart for reasons outside of her control, she always kept her poise (and had a quality answer). Her feathers couldn’t be ruffled, and that’s because her knowledge level is as absolute as the StackNavigator being used in your favorite (React Native) mobile app.

The workshop play-by-play

Kadi started off with a brief introduction to React Native, emphasizing the fact that it enables developers to build an application for both iOS and Android, without having to use separate code bases for each (for reference, in order to build mobile apps in the past, you would need to write Objective-C/Swift code for iOS, and Java/Kotlin for Android). This key feature was largely why I chose to give React Native a try. Hard pass on writing two codebases for the same application.

After the introduction, she discussed the environment setup, and went over the differences between using the Expo CLI, vs. using the React Native CLI. For this course — and for beginners — she suggested using Expo, as it would make it much easier to get up-and-running; not to mention the suite of built-in tools that enhance the development experience. Mr. Net Ninja concurs.

While she went through the installation and environment setup processes, I skipped ahead and continued reading through her outline. I installed the extra dependencies related to navigation, and reluctantly installed eslint as well. I say reluctantly, because, eslint can really get on my nerves when it continues to yell at me over and over again (but I understand and see its value).

Once we got into the debugging topic, my ears perked up when I heard there was a way to use a debugging tool similar to the web-based console. While completing the Net Ninja tutorial, it bothered me that it seemingly didn’t exist. Obviously I didn’t try very hard to find it, as the command to open it up (on Android/Windows) is a simple Ctrl + m, followed by a click of the Debug button — and one more minor step after that.

After the debugging talk, Kadi went over the basic Components. One of the cool things I learned there was the usefulness of the <SafeAreaView> component. By wrapping <SafeAreaView> around your application, your content will not overlap on the top and bottom of the screen. Very handy.

Styling and .css came next, and it’s not much different than what you’d use when creating web applications. The first notable difference is that sizes are pixel based, and you don’t include a px or rem when defining a size. It’s 1, rather than 1px.

Another variation is that flexbox is used by default, and snake-case is no longer in use, as background-color becomes camelCased to backgroundColor.

The last noteworthy .css difference is how you inject styles into your components. With React Native, you complete the following: you import a <StyleSheet>, add a const called styles, and equal it to the StyleSheet.create({}) method. Within this method, you create “classNames” such as container, and inject the styling into components like so: <View style={styles.container}>. This reminded me a lot of the similarly-structured, styled-components library.

The one piece of React Native .css code I hadn’t seen prior to the workshop, was using an array to add multiple styles into a particular component <View style={[styles.firstStyle, styles.secondStyle]}. This isn’t mind-blowing by any means, but it was something cool that I didn’t know before.

Then once the Styling talk was finished, Kadi presented us with our first exercise. Our goal was to create four rectangle boxes filled with different backgroundColors, and white text that specified what the color was. This exercise was relatively simple, and I didn’t have any issues completing it.

After that exercise, we moved onto functional components, with examples of props being passed into them. If you’ve used React before, you’re probably very aware of how that works. There doesn’t seem to be any difference there.

But where there is a difference, is how you .map through items in an array. With React Native, you want to use a <FlatList> or a <SectionList>, rather than straight-up mapping. You want to go this route because mapping will render every element in an array, all at once, regardless of whether it is visible on the screen. With <FlatList>, you don’t get that nonsense. Your entire array isn’t loaded all at once. Your list loads as it appears on the page, which improves both performance and the user experience — especially when dealing with large arrays of data.

Once Kadi went over the built-in properties of the List components, we moved onto the Lists exercise, where we rendered a long list of boxes with their respective colors and text.

Aside from changing the text color based upon the color of the background (you don’t want white on a light background, after all), this exercise wasn’t too difficult. A simple <FlatList> component taking in an array of data and rendering a reusable <Component> with props, in the same style as before, wasn’t too much to ask.

After Kadi live-coded the solution to the exercise, we moved onto the topic of Navigation, and installed the appropriate dependencies related to it.

Navigation boils down to two possibilities: Bottom navigation and Stack navigation. Bottom navigation typically consists of clickable icons at the bottom of your screen, and they bring you to a new page/screen when you press them. Stack navigation consists of a user pressing something (text/buttons/images) that links the user to the appropriate new screen (or page, if you’re thinking in terms of web development). We didn’t go into bottom navigation, but Kadi gave us the low-down on stack navigation, along with an overview and example of “touchable” components (buttons in web speak).

Shortly thereafter, the next exercise was presented to us. The end goal was to display three separate color blocks on the home screen, and navigate to a new screen that included the relevant set of colors, once you clicked on the color block.

Well, there were a lot more moving pieces in this exercise, and since I wasn’t extremely comfortable with Navigation quite yet, I needed more time to make it fully functional. I was unable to complete this exercise in the allotted time, unlike the seasoned-vet sitting on my left. So. Very. Jealous.

From there, we went into React’s newest state management system: Hooks.

The beauty of Hooks is that you’re able to add state to basic function components. A class component or Redux isn’t 100% required any more. Aside from this efficiency upgrade, the hooks are also relatively easy to understand, and the useEffect hook makes the mounting lifecycle quite simple. With that said, I haven’t used them very much, but I can appreciate their versatility and usefulness. The hook is certainly a useful tool. Just be careful you don’t cut yourself with it.

Kadi demonstrated an increment/decrement example with useState, and then moved onto useCallback, followed by useEffect.

The useState hook is very straightforward and I already had a good understanding of how to use it. With it, you declare your initial state; you include a variable name that holds your initial state value; and you create a function name to change said variable. const [value, setValue] = ({“yourInitialStateValue”})

The useCallback hook was not something I was familiar with beforehand, but afterhand, it felt like a brother to me. The main takeaway was that useCallback prevents the app from re-rendering each time a setState function is called. You throw the setState function in the useCallback hook, and you’re as good as gold.

The useEffect hook was intimidating and where I ran into a mental wall. After reading about it a little more, though, it doesn’t feel as daunting. That’s because it’s much like the familiar-to-me method, componentDidMount. The difference being, it will also “do something” upon unmounting if you want it to, which means you can lump in the logic for both within the same method. The main point Kadi hammered home here, was adding the empty array as the second argument. Apparently it is very easy to skip. She also noted that if you pass values into the array, you can trigger a constant re-render, and wind up with an aggravating infinite loop. So, you must be careful of what variables you place within the array. Say NO to memory leakage.

After going through the hooks, it was onto the next exercise. This exercise consisted of a completing a network request with Hooks, and rendering the data we received in a <FlatList> component. Unfortunately for me, my brain was feeling overloaded, and I couldn’t conceptualize the step-by-step process of what needed to be done in the allotted time. I needed to read through the solutions to push me along. And yes, you can be certain the whiz next to me completed it without a hiccup.

We then moved onto the RefreshControl property for rendering lists and fetching data. This is essentially a built-in “your app is loading” method that is extremely easy to configure, and automatically included as an option to scrollable components. Yet another pleasant built-in surprise by React Native.

Forms were the next topic of conversation. In the Net Ninja tutorial, a 3rd party library called Formik was used to handle the inputting process. I wasn’t crazy about using a 3rd party library for this, so I was pleased when Kadi went over the Native-based, vanilla version.

The truth is there are only slight variations between using inputs with web, and using inputs with mobile. The main difference, I’d say, is toggling the keyboardType property to render either: your standard text keyboard, or variations of number keypads. There weren’t too many startling surprises here.

But I was in for a surprise during the discussion about Modals. In the Net Ninja tutorial, I didn’t need to tinker with Navigation to launch a modal. The Modal was imported with the other standard components (<View>, <Text>, etc) and rendered based upon the pressing of a button. In Kadi’s example, we needed to refactor our Navigation into two different stacks. This was initially difficult to wrap my head around, but luckily, it makes much more sense now.

And finally, we were onto the last exercise; which was everything we had done already, paired with the addition of a Modal that included a form to create your own custom color palette. If reading that was a mouthful for you, you can imagine what that did to my mentally-tapped-out brain at the time.

But for Kadi, it was nothing. She live-coded and explained this elaborate exercise masterfully. Even though it would have taken me all day to complete it on my own, with her explanations, I felt like I could wrap my head around it. As she went through the solution, I understood each and every piece of code she added — just like I did during the rest of the course. Needless to say, she was an excellent instructor, and it was a privilege to learn from someone so skilled. The opportunity to learn from her was something I’m extremely grateful for. Thank you Kadi, it was a pleasure!

Workshop Retrospection

The workshop lived up to the excitement level that brewed inside of me during the days leading up to it. I was not let down; I got what I came for on this atypical day of mine. As a result of this workshop, I now have a solid understanding to the basic fundamentals of React Native. Had I not been invited, I doubt I would even have my environment set up.

This would have been a shame since learning React Native was something I’ve been eager to do. One part because of my desire to master all things React; one part because I had an idea for a micropayment-incorporating, entertainment app made exclusively for mobile; and one part because I increase my value as a developer by knowing it. Win-win-win, all the way around.

Obviously, this was just an introductory workshop and I’m not going to become a pro just because I took it, but it lays the groundwork for me to build upon and reach that level at a later date. Learning code is a process after all, and the more experience you have, the better off you are. And what better way to get that start, than by learning from the best.

My only regret to the whole thing was not sticking around to chat with Marc, Kadi, and the other developers in attendance. My intention was to connect with people there, but my nerves were going haywire from the moment I walked in the door (being out of my comfort zone and building it up in my head), so I couldn’t muster up the courage. I ended up skedaddling out of there without saying a word to anyone — the exact opposite of how I wanted to finish the day. But hey, what can you do when you’re feeling crippled at the throat?

Final Words

If you’re a developer and you haven’t checked out Frontend Masters or their courses, you really owe it to yourself to do so. I couldn’t have been more pleased with them and the workshop they put on. From the CEO interactions and know-how of the instructor, to the catered Chipotle and comfy mesh chairs, the workshop was fantastic all around. Frontend Masters continues to impress and deliver.

Thanks again for allowing me to participate.

Until next time,

Sam