• Complexity is transparent All this adds up to great benefits - as the code gets more complex, the coder will be in the best position to actually deal with the complexity as it comes up, rather than stuffing it away to cause problems overtime. It's hard to fully explain just how important it is to keep code linear and complexity at a minimum - when you work on a project long enough, it pays back dividends. Pretty code, as time goes by, just incurs a greater and greater cost.

---

An alternative to a global stylesheet in React Native

Posted: 7/7/2020

Problem: Stylesheets

The traditional method for dealing with this problem is to extract all your styling, and put them in a stylesheet file and reference that everywhere.. (think html + a global css stylesheet) I find that creates two problems: 1. Styling becomes harder to tinker with I can’t make changes to appearance without taking into consideration the structure of the code, so now I have to open up two files, and hold the mental connection between the style code and the structure code in my head while I make changes. But also, I have to simultaneously hold in my head everywhere this stylistic code could be used (For example, a button color) in order to make sure I’m not creating a problem somewhere else in the app. In practice this becomes an exponentially difficult problem the more the style code is used. 2. The stylesheet file becomes a mess of rotten code and redundancy In order to delete a style, you’d have to search everywhere it’s used, and inline style code for classes who are used too infrequently to be useful, this is a highly bug prone and tedious task so in practice, old styles rarely get deleted. The global stylesheet becomes a scary mess of styles that can not be deleted + new redundant styles that are created to compensate for this. Individual colors + font size can be redundant too, since Stylesheet properties can not reference other properties created within the same object, requiring the creation of local variables. These two problems can override any benefit of style conformity this method offers.

Solution: Collection of Components

Fortunately, I've landed on a way I like much better for now: Creating component files that are collections of similar elements (like Buttons.js, or Text.js for labels and such). This method comes with a number of benefits. 1. Easy to delete These can be named specifically to indicate where they are used, which makes it much easier to delete unused components as needed. 2. Simple reuse Components can be made up of elements of other components, or can just include variables (referencing colors, fontsizes, etc) used in other components. This gives much more flexibility than the stylesheet method, while not enforcing reuse where not helpful. 3. Easy Hackability Want to create a new button? Just copy an existing Button that matches the design and paste it at the bottom of the file + tweak way. There is no unnecessary coupling! Example:

Buttons.js

// Confirm Button
const ConfirmButton = ({bgColor, textColor, children, onPress}) => {
    return(
        <TouchableOpacity style={{backgroundColor:bgColor}} onPress={onPress}>
            <Text style={{fontSize:confirmFontSize, color:textColor }}>{children}</Text>
        </TouchableOpacity>
    );
};
export const NoConfirmButton = ({children, onPress}) => {
    return(
        <ConfirmButton bgColor="#ffffff" textColor={confirmNoTextColor}
            onPress={onPress}>{children}</ConfirmButton>
    );
};
export const YesConfirmButton = ({children, onPress}) => {
    return(
        <ConfirmButton bgColor={accentColor} textColor={lightTextColor} 
            onPress={onPress}>{children}</ConfirmButton>
    );
};

---

One Level Deeper - A Handmade Lesson applied to React Native

Posted: 7/3/2020 For this project, I had to create a Drawer - a little sliding thing that sweeps in from the right of the screen. Of course there is a Drawer react native element, but it's a black box, and would of required me to change the design, or hack it to get it to work the way I wanted. So I'm practicing something that I heard in a Handmade Network Podcast. The quote is something like: "Go one more level deeper than I need" The idea here is that if I go one level deeper than I actually need, I'll be able to fix bugs easier, and extend and enhance better as well. So looking at the source code about the Drawer I found that it was super complex, and I really had to deeply consider if I wanted to go on this journey. But I time boxed it to a few hours, and was able to distill it to it's essential elements. A PanGestureHandler, and a few Animated.Views.

<PanGestureHandler
onGestureEvent={this._onPanGestureEvent}

<View style={{ flex: 1, }}>
  <Animated.View
    style={{
      transform: [
        {
          translateX: Animated.subtract(new Animated.Value(0), this._dragDistance),
        },
      ],
    }}
  >
    {this.mapRender()}
  </Animated.View>
</View>
</PanGestureHandler>

The temptation with React Native is to use components that already exist with the idea of saving time. It's true that initial development time is saved, but when you want to make a small tweak that falls outside the parameters of what the component allows, or something changes and the component starts throwing a cryptic error, you end up with a much more challenging problem - trying to hack or diagnose a black box. And generally when you've got the urgency of a bug, or a small tweak, the idea of doing a lower level rewrite seems like a bad use of time. Provided that the lower level implementation isn't too costly, it's best to pay that small cost earlier, rather than get stuck with a hacked solution later. So now I have code that is way more flexible and powerful, and much simpler, because it's not generic code. This is something that is worth the cost.