Head Banging

This week, I started working on a brand new topic for me, React Native. React Native does share a lot it common with React, but of course, it's quite different at the same time. With React, the developer uses web-based components, while in React Native, everything is eventually translated to IOS or Android code and therefore, typical HTML and CSS are not available. React Native simply uses the constructs a JavaScript/React developer would be accustomed to so it is easier and more familiar to them. However, for example, instead of using divs as container elements, everything is put into Views, which is a built-in component for React Native. All of these components come with their own set of styling features which look very similar to CSS, but are not. All View components are flex-based by default, so with that in mind, the developer can style these components in a suitable manner. Instead of having CSS files or even CSS on the same file, all of the styling is placed into JavaScript objects and the StyleSheet component is used to translate these objects into the native code. This ends up looking very similar to CSS in JS, where all of the CSS is put into JavaScript objects and then called with dot notation.

Most of the code so far has been pretty straightforward to understand; I haven't had any issues there. In Maximilian Schwarzmüller's React Native - The Practical Guide, we are still in the exploration phase, learning all of the new syntax and applying a lot of different styling to the components we are creating. I've noticed that a lot of these components have to be wrapped by View components to get the desirable styling, which is a little annoying, but not that different to what you would do with divs in React. This is mainly due to the fact that only certain styling rules work with certain types of components. For example, Views by default are flex-based, while Text or Buttons are not, so you wouldn't have the option to style those in a way that would be flex-based, not that you would anyways. A more applicable example is trying to apply a width to a button. If I wanted to apply a width to a button, I would first have to wrap it in it's own View component and then style that View component with a width. This has come up several times in the apps we've been building so far. While I can totally understand why React Native is built in this way, it's going to take some getting used to.

Error handling is pretty solid in React Native, but nothing compared to React. This, coupled with a completely different workflow with React Native caused me about an hour of headache this evening. With React Native, the best way to make sure the app looks the way you want it is to have 2 simulators up and running at the same time, one of an Android phone through Android Studio and one of an IPhone through XCode. While it's kind of cool to be able to see exactly how this looks, I've had some serious issues with hot reloading so far. I made a simple error in my code today, forgetting to add the default export at the bottom of one of my components. It took me entirely too long to figure out what I'd done wrong, but in the meantime, both of my simulators became pretty much unresponsive. I shut them down and booted them back up, but kept getting a really obscure error reference that didn't really explain anything. It basically pointed me to some module not being callable, which turns out was the component I hadn't exported. When I fixed this, my simulators were still giving me the error, so I thought I must have some other error. I tried rebooting them several times, which takes a lot of time to do, and kept getting the error. Finally, I thought I would try to restart the server completely and reboot the simulators, and it finally worked. In a React app, if I had made an error like that, the error handling would have been much more explicit and, upon fixing it, the hot reload would have worked right away. In conclusion, I'm not in love with the workflow right now, and I hope I can find a more efficient way to go about my business soon.

Until tomorrow!