Forem: Ben McMahen

A Beginner's Guide to Generics in Typescript

Ben McMahen — Fri, 12 Jul 2019 18:36:24 +0000

Can’t quite wrap your head around generics in typescript? The best way to explain generics, in my opinion, is by analogy.

Consider a courier service like UPS or Puralator that delivers packages around the world. The courier service doesn’t need to know the exact nature of the parcel - they don’t need to know if it’s a toy, book, clothing item, etc., - but the expectation is that the recipient will receive that which was sent. If a toy is sent, a toy will be received. The courier is in charge of delivering that package, but doesn’t need to know the exact type of content that it’s delivering.

In this analogy, the courier service is our function and the package is our generic. Let’s try to clarify this analogy with some code. This example (which doesn’t use generics) shows a courier function which receives a string as an argument, and returns a string. Our return value delivery is correctly typed as a string.

function courier(package: string): string {
  return package
}

// delivery is typed as a string
const delivery = courier('book')

But presumably we want our courier function to be able to handle more than just strings. We should be able to handle numbers, objects, or anything…

We might be tempted to achieve this using the any type.

function courier(package: any): any {
  return package
}

// delivery is typed as any
const delivery = courier('book')

This works, but now our delivery value is typed as any. But shouldn’t the caller of the function - the person sending the package - know the type of the package returned? In other words, wouldn’t it be nice if our delivery value retained whatever type the package was initially assigned? If our package is a string, our delivery should be a string. If it’s a number, our delivery should be a number… and so on.

This is where generics come in. Let’s write the same function using generics:

function courier<T>(package: T): T {
  return package
}

// delivery is typed as string
const delivery = courier('book')

// lucknumber is typed as number
const luckynumber = courier(7)

T is a type variable. You don’t need to use T, but it’s standard practice. Basically, this syntax reads as: “Courier accepts a generic type, represented as T. This generic type is defined by our package argument, and our courier function returns a value of the same type.”

Maybe our courier should be able to accept multiple packages at once.

function courier<T>(package: T[]): T[] {
  return package
}

// typed as [string, number]
const delivery = courier(['book', 7])

And there you have it. Our courier function now accepts an arbitrarily long array of packages, and correctly types that array in the return value.

This is just the start, but hopefully you see how generics are particularly useful for creating reusable, flexible functions and classes.

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

An Introduction to SwiftUI for React Developers

Ben McMahen — Wed, 12 Jun 2019 21:34:59 +0000

If you’ve been working with React for a while and you take a quick glance at Swift UI you can probably spot the similarities almost immediately. Both are declarative UI frameworks which emphasize a separation between state and the templates used to generate views. Both emphasize reactivity - update your state to update your views. And both emphasize the creation of components which can be composed together to create reusable, complex views.

Honestly, your biggest hurdle in picking up SwiftUI will probably be learning Swift itself and working with a typed language. Having some experience with typed languages, including Typescript, is useful.

In this article I’ll be walking through some very basic SwiftUI design patterns from the perspective of a React and Javascript developer. You can find more of these patterns in the react-meets-swiftui github repository.

Using state in Swift UI

Let’s take a look at a very simple SwiftUI component.

struct Counter : View {
    @State var counter = 0

    func increment () {
        counter += 1
    }

    var body: some View {
        VStack {
            Text("Count: \(counter)")
            Button(action: increment) {
                Text("Increment")
            }
        }
    }
}

This looks quite similar to creating a React component class. We are defining a struct named Counter which is a class-like construct that includes properties and functions. View describes a protocol that our Counter must follow — i.e., it must contain a body property which returns some View. If we remove the body property from our struct the compiler will complain that we aren’t adhering to the View protocol.

This body property is similar to the render function that you find in React. And its contents are similar to JSX. In this case, we have composed 4 Views (VStack, Text, Button, and Text) in our counter to create a vertical stack containing a text label and a button which increments our value.

The @State property defines our local component state. @State defines a property wrapper which is a new Swift language feature. It ensures that our property is reactive. We define its default value as 0 and its type as Int is automatically inferred. To reactively update the value we can simply change the counter property and our view will rerender accordingly. This is the equivalent of running setState in React.

Passing props to components

Passing props is as easy as defining arguments in a function. Let’s look more closely at the body property of our Counter view.

var body: some View {
    VStack {
        Text("Count: \(counter)")
        Button(action: increment) {
            Text("Increment")
        }
    }
}

Notice that both Text and Button are view structs which accept arguments. These arguments are the equivalent of React’s props. In this case, Text accepts a String while our button accepts a function which is called when a touch occurs.

But what about that value which is contained within the brackets after VStack and Button? This is a trailing closure and a relatively new feature of Swift. Basically, the trailing closure syntax is a piece of syntatic sugar which allows you to write the final argument of a function (when it’s a closure) after the function declaration.

Instead of:

Button(action: increment, content: () -> Text("Increment"))

We can write:

 Button(action: increment) {
    Text("Increment")
}

To understand how to create a custom View which accepts props, let’s create another View which will help us render our counter. It should accept a count prop from the parent component.

struct CountDisplay : View {
    var count: Int
    var body: some View {
        HStack {
          Text("Your count total:")
          Text("\(count)")
        }
    }
}

And let’s pass the count prop from our parent view to our CountDisplay.

var body: some View {
    VStack {
        CountDisplay(count: counter) Button(action: increment) {
            Text("Increment")
        }
    }
}

Similar to React, isn’t it?

Updating parent state in child views using binding

One common pattern in React is to pass onChange callback functions to child components such that parent components can update and change its local state, which will then propagate to the child components. You can do the same in SwiftUI, but SwiftUI goes one better — it allows child components to update parent state.

Let’s refactor our Counter example so that our Button appears in a child component.

struct IncrementButton : View {
    @Binding var counter: Int
    func increment () {
        counter += 1
    }

    var body: some View {
      Button(action: increment) {
          Text("Increment")
      }
    }
}

So now our child IncrementButton accepts a counter prop, and it can actually update that prop itself. No onChange callback necessary! It updates that prop in the parent component where it came from. Pretty cool! We use the special @Binding property decorator to ensure that a bound variable is passed as a prop to our components.

How do we pass a bound variable? Let’s redo our parent component.

struct ContentView : View {
    @State var count = 0

    var body: some View {
        VStack(spacing: 1.0) {
            Text("Press the button below")
            IncrementButton(counter: $count) }
    }
}

We simply prepend an $ symbol prior to the state variable that we are passing.

Other React Design Patterns in SwiftUI

Obviously, this is just the start when it comes to implementing React design patterns in SwiftUI. But I’ll be exploring additional patterns over the coming months and recording my observations.

You can view additional React patterns in the react-meets-swiftui repository. If you’re a React developer and want to learn the basics of SwiftUI, this is a great place to start.

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

React design patterns in SwiftUI

Ben McMahen — Thu, 06 Jun 2019 19:58:16 +0000

TLDR: I've created a repository with React patterns implemented in SwiftUI

Apple has recently released SwiftUI, a declarative UI framework for building native applications on Apple devices. The similarities with React are quite obvious, which makes it relatively easy for any React developers to pick up.

I'm going to be teaching myself SwiftUI over the coming weeks and I'll be recording various common React design patterns implemented in SwiftUI. You can see them on the react-meets-swiftui GitHub repository. The hope is that these examples will make it easier for experienced React developers to pick up SwiftUI.

Please keep in mind that I have about 4 years of React experience, and 3 days of Swift experience. But I'll continue to update these examples as I learn more, and hopefully those with more experience will offer their help.

Advanced Gestures on the Web - iOS in React

Ben McMahen — Mon, 27 May 2019 17:35:44 +0000

I've been working a lot with building react components recently that support gesture controls - things like swipe to open / close, pinch to expand... basically, all of the stuff that is standard in native apps but is relatively rare on the web.

My conclusion: It's actually quite possible... and FUN! So much fun, in fact, that I got carried away with a little demonstration app. I thought, what better way to prove that advanced gestures are possible on the web than by reimplementing the iOS home screen functionality?

So here it is: react-iphone.

View the demo.

Browse the source.

Try long pressing an icon to enable drag and drop. Swiping up, down, left or right at various parts of the screen will trigger some of the behavior that you expect in iOS. It's not all there, but I think it proves the point.

It's built using react-gesture-responder and react-spring. I also wrote a short tutorial on how to use these tools to implement a "swipe to like" feature.

It works pretty well in iOS Safari too (just enter full screen)! Haven't had the chance to try android yet, so I'd love to get some feedback there.

A Beginners Guide to using Typescript with React

Ben McMahen — Thu, 23 May 2019 20:03:01 +0000

Having spent the last few months developing React applications and libraries using Typescript, I thought I’d share some of the things I’ve learned along the way. These are the patterns I use with Typescript and React about 80% of the time.

Is it worth learning Typescript for developing React applications? Absolutely. I’ve found that having robust typing has led to more reliable code and faster iteration especially within a larger codebase. You’re likely to be frustrated at first, but as you work through it you’ll find that the minimal extra boilderplate is very much worth it.

And if you get stuck on something, remember that you can always type something as any. Any is your friend!

Let’s get to the examples.

Your basic react component with typescript

So what does a standard react component look like with typescript? Let’s compare it to a standard javascript react component.

import React from 'react'
import PropTypes from 'prop-types'

export function StandardComponent({ children, title = 'Dr.' }) {
  return (
    <div>
      {title}: {children}
    </div>
  )
}

StandardComponent.propTypes = {
  title: PropTypes.string,
  children: PropTypes.node.isRequired,
}

And now the typescript version:

import React, { ReactNode } from 'react'

export type StandardComponentProps = {
  title?: string;
  children: ReactNode;
}

export function StandardComponent({
  children,
  title = 'Dr.',
}: StandardComponentProps) {
  return (
    <div>
      {title}: {children}
    </div>
  )
}

Pretty similar, eh? We’ve replaced our propTypes with a typescript type. Our title prop remains optional, while a children prop is required. We’ve exported our type in case another component needs reference to it.

Extending standard HTML attributes

If we want the parent component to be able to provide additional typed div attributes, such as aria-hidden, style, or className we can either define these in our type or we can extend a built in type. In the example below, we are saying that our component accepts any standard div props in addition to title and children.

import * as React from 'react'

export type SpreadingExampleProps = {
  title?: string;
  children: React.ReactNode;
} & React.HTMLAttributes<HTMLDivElement>;

export function SpreadingExample({
  children,
  title = 'Dr.',
  ...other
}: SpreadingExampleProps) {
  return (
    <div {...other}>
      {title}: {children}
    </div>
  )
}

Handling events

We can type our event handlers to ensure that our event argument is typed properly. The below example demonstrates various ways of achieving this:

export type EventHandlerProps = {
  onClick: (e: React.MouseEvent) => void;
}

export function EventHandler({ onClick }: EventHandlerProps) {
  // handle focus events in a separate function
  function onFocus(e: React.FocusEvent) {
    console.log('Focused!', e.currentTarget)
  }

  return (
    <button
      onClick={onClick}
      onFocus={onFocus}
      onKeyDown={e => {
        // When using an inline function, the appropriate argument signature
        // is provided for us
      }}
    >
      Click me!
    </button>
  )
}

Unsure which argument signature to use? In your editor trying hovering your cursor over the relevant event handler prop.

Using string literals

Do you have a prop which requires a string which matches a set of pre-defined options? You can use the typescript string-literal for this.

type Props = {
  title: "senior" | "junior";
}

function Label({ title }: Props) {
  return <div>Title: {title}</div>
}

Now if the title is anything other than senior or junior, typescript will yell at you.

Using Generics with your react components

This is more of an advanced feature, but one that is really powerful. Typically you’ll define data types in your react components with their specific attributes. Let’s say your component requires a profile object.

type ProfileType = {
  name: string;
  image: string;
  age: number | null;
}

type ProfilesProps = {
  profiles: Array<ProfileType>;
}

function Profiles(props: ProfilesProps) {
  // render a set of profiles
}

But now let’s imagine that you have a component which can accept an array of any type. Generics are analogous to sending a parcel in the mail. The courior (our component) doesn’t need to know the exact contents of the parcel that you’re sending, but the sender (parent component) expects the recipient to get the contents that they sent.

Here’s how we do it:

type GenericsExampleProps<T> = {
  children: (item: T) => React.ReactNode;
  items: Array<T>;
}

export function GenericsExample<T>({
  items,
  children,
}: GenericsExampleProps<T>) {
  return (
    <div>
      {items.map(item => {
        return children(item)
      })}
    </div>
  )
}

A bit of a weird example… but it demonstrates the point. The component accepts an array of items of any type, iterates through that array and calls children as a render function with the item object. When our parent component provides the render callback as a child, the item will be typed properly!

Don’t get it? That’s okay. I still don’t fully understand generics either, but you’re unlikely to need this very often. And the more you work with typescript, the more it’ll make sense.

Typing hooks

Hooks mostly works out of the box. The two exceptions are sometimes useRef and useReducer. The below example demonstrates how we can type refs.

import * as React from 'react'

type HooksExampleProps = {}

export function HooksExample(props: HooksExampleProps) {
  const [count, setCount] = React.useState(0)
  const ref = React.useRef<HTMLDivElement | null>(null)

  // start our timer
  React.useEffect(
    () => {
      const timer = setInterval(() => {
        setCount(count + 1)
      }, 1000)

      return () => clearTimeout(timer)
    },
    [count]
  )

  // measure our element
  React.useEffect(
    () => {
      if (ref.current) {
        console.log(ref.current.getBoundingClientRect())
      }
    },
    [ref]
  )

  return <div ref={ref}>Count: {count}</div>
}

Our state is automatically typed, but we have manually typed our ref to indicate that it will either be null or contain a div element. When we access our ref in our useEffect function, we need to ensure that it’s not null.

Typing a reducer

A reducer is a bit more complex, but having it properly typed is really nice.

// Yeah, I don't understand this either. But it gives us nice typing
// for our reducer actions.
type Action<K, V = void> = V extends void ? { type: K } : { type: K } & V

// our search response type
type Response = {
  id: number;
  title: string;
}

// reducer actions. These are what you'll "dispatch"
export type ActionType =
  | Action<'QUERY', { value: string }>
  | Action<'SEARCH', { value: Array<Response> }>

// the form that our reducer state takes
type StateType = {
  searchResponse: Array<Response>;
  query: string;
}

// our default state
const initialState: StateType = {
  searchResponse: [];
  query: '';
}

// the actual reducer
function reducer(state: StateType, action: ActionType) {
  switch (action.type) {
    case 'QUERY':
      return {
        ...state,
        query: action.value,
      }

    case 'SEARCH':
      return {
        ...state,
        searchResponse: action.value,
      }
  }
}

type ReducerExampleProps = {
  query: string;
}

export function ReducerExample({ query }: ReducerExampleProps) {
  const [state, dispatch] = React.useReducer(reducer, initialState)

  React.useEffect(
    () => {
      if (query) {
        // emulate async query
        setTimeout(() => {
          dispatch({
            type: 'SEARCH',
            value: [{ id: 1, title: 'Hello world' }],
          })
        }, 1000)
      }
    },
    [query]
  )

  return state.searchResponse.map(response => (
    <div key={response.id}>{response.title}</div>
  ))
}

Using `typeof` and `keyof` to type component variants

Let’s say we wanted to build a button with various appearances, each defined in an object with a set of keys and styles, like this:

const styles = {
  primary: {
    color: 'blue',
  },
  danger: {
    color: 'red',
  },
}

Our button component should accept a type prop which can be any key of the styles object (i.e, ‘primary’ or ‘danger’). We can type this quite easily:

const styles = {
  primary: {
    color: 'blue',
  },
  danger: {
    color: 'red',
  },
}

// creates a reusable type from the styles object
type StylesType = typeof styles

// ButtonType = any key in styles
export type ButtonType = keyof StylesType

type ButtonProps = {
  type: ButtonType
}

export function Button({ type = 'primary' }: ButtonProps) {
  return <button style={styles[type]}>My styled button</button>
}

These examples should get you 80% of the way there. If you get stuck, it’s often worth looking at existing open source examples.

Sancho UI is a set of react components built with typescript and emotion.

Blueprint is another set of react components built with typescript.

Building React Components with Gesture Support

Ben McMahen — Wed, 08 May 2019 18:07:33 +0000

It’s perhaps not suprising that gesture support isn’t particularly common on the web. Adding intuitive gestures that match their native counterparts can seem quite daunting and often not worth the trouble. But c’mon, it’s 2019 and the mobile web deserves some decent gesture support!

This article will walk you through the creation of a basic list item which allows you to swipe left to “like” it — a pattern fairly common in native apps, and one that I use quite often in Spotify. Here’s what our final version will look like:

Before getting started, it’s useful to have a basic understanding of React and React hooks. Ready? Let’s do this.

The basic component layout

Before adding any gestures, we need a basic component skeleton & layout. Let’s create a component with a wrapper div element and two children: one will be our background with the heart icon, and the other will provide our sliding foreground element.

Our component will look something like this:

import React from 'react'
import { Heart } from 'react-feather'

function Slider({ children }) {
  return (
    <div className="list-item">
      <div className="background">
        <Heart />
      </div>
      <div className="sliding-pane">{children}</div>
    </div>
  )
}

Our styles are fairly simple. Let’s use a predefined width and height for the list-item element and give it a relative position. And then let’s assign an absolute position to our sliding-pane. Our full css will look like this:

.list-item {
  position: relative;
  width: 300px;
  height: 75px;
  box-sizing: border-box;
  display: flex;
  align-items: center;
  text-align: center;
  border-radius: 0.5rem;
}

.sliding-pane {
  cursor: -webkit-grab;
  background-color: #121212;
  color: rgba(255, 255, 255, 0.9);
  position: absolute;
  height: 100%;
  width: 100%;
  display: flex;
  align-items: center;
  justify-content: center;
  border-radius: 0.5rem;
  font-size: 1.25em;
  font-weight: 600;
}

.sliding-pane:active {
  cursor: -webkit-grabbing;
}

.background {
  align-self: stretch;
  display: flex;
  flex: 1;
  justify-content: flex-end;
  align-items: center;
}

Alright, we have our basic skeleton. But it doesn’t do anything! Time for some gestures.

Adding drag gestures with react-gesture-responder.

To add gestures we are going to use a library that I developed called react-gesture-responder. React gesture responder is a hook that binds to an element and provides gesture callbacks for that element. It’s a fairly low-level library that allows you to build (and negotiate between) complex gestures. Let’s add it to our component:

import { useGestureResponder } from 'react-gesture-responder'

function Slider({ children }) {
  const { bind } = useGestureResponder({ // the view should claim the responder when touched onStartShouldSet: () => true, onMove: state => { // move callback }, onRelease: state => { // release callback }, })
  return (
    <div className="list-item">
      <div className="background">
        <Heart />
      </div>
      <div {...bind} className="sliding-pane"> {children}
      </div>
    </div>
  )
}

The useGestureResponder hook returns a bind object and accepts a number of callbacks. These callbacks help us control and respond to our gestures.

The bind object should be spread on the element you want to accept gesture controls. What is the bind object, exactly? It’s a collection of event callbacks, such as onTouchStart, onTouchMove, etc., which the hook uses to determine its gestures.

The onStartShouldSet callback tells the view to claim the responder for itself. Typically, you’ll always return true for this unless you want to disable gesture interactions altogether. (Note: you may want to return false in more complex cases involving negotation between competing gestures. But that’s for another tutorial.)

The onMove function is called when a drag is performed, while onRelease is called when that drag ends.

Let’s use these callbacks to update the position of our slider.

function Slider({ children }) {
  const [x, setX] = useState(0)
  const { bind } = useGestureResponder({
    onStartShouldSet: () => true,
    onMove: state => { const [x] = state.delta setX(x) }, onRelease: state => { setX(0) }, })

  return (
    <div className="list-item">
      <div className="background">
        <Heart />
      </div>
      <div
        {...bind} style={{ transform: `translateX(${x}px)`, transition: `transform 0.2s ease`,
        }}
        className="sliding-pane"
      >
        {children}
      </div>
    </div>
  )
}

Our slider now responds to our drag movements and animates back into place upon release.

But there are a few problems with this code:

The transition animation is performed even while dragging. It’d be nice if this was immediately responsive while dragging, but animated upon release.
Performance isn’t great because each update to component state causes our entire component to rerender. This might not be a huge issue for a small component like this, but you can imagine performance degrading over time with more complex components.

My preferred solution to these problems is to use an animation library like react-spring.

Using react-spring for better control and performance.

React-spring exposes a useSpring hook which we can use in place of our x state.

Let’s replace this:

const [x, setX] = useState(0)

with useSpring:

import { useSpring } from 'react-spring'

const [{ x }, set] = useSpring(() => {
  return { x: 0 }
})

We now perform animation updates by calling the set function instead of setX.

set({ x: 100 })

React-spring also exports an animated component. These should be used in place of regular div elements when using spring values such as our x value. Let’s put this together:

import { useSpring, animated } from 'react-spring'

function Slider({ children }) {
  const [{ x }, set] = useSpring(() => { return { x: 0 } })
  const { bind } = useGestureResponder({
    onStartShouldSet: () => true,
    onMove: state => {
      const [x] = state.delta
      set({ x, immediate: true }) // the immediate flag bypasses the transition animation },
    onRelease: state => {
      set({ x: 0, immediate: false }) },
  })

  return (
    <div className="list-item">
      <div className="background">
        <Heart />
      </div>
      <animated.div {...bind} style={{ transform: x.interpolate(x => `translateX(${x}px)`), }} className="sliding-pane"
      >
        {children}
      </animated.div>
    </div>
  )
}

This provides the same functionality as the previous example but fixes both problems mentioned earlier. Performance is improved. And notice the immediate option when calling our set function? This disables the spring transition animation, which provides us with responsive dragging. We disable immediate on release to enable the animation.

Determining when the user has ‘liked’ the list item.

Lastly, we need to determine when the user has gestured far enough to the left to trigger a “like”, and we need to provide visual feedback to the user when they have reached this threshold.

function Slider({ children }) {
  const [isLiking, setIsLiking] = React.useState(false);
  const [{ x }, set] = useSpring(() => {
    return { x: 0 }
  })

  function shouldLike(x) { return x < -100 }
  const { bind } = useGestureResponder({
    onStartShouldSet: () => true,
    onMove: state => {
      const [x] = state.delta
      const like = shouldLike(x) if (like !== isLiking) { setIsLiking(like) }
      set({ x, immediate: true })
    },
    onRelease: state => {
      if (shouldLike(state.delta[0])) { cosole.log('User has liked!) }
      set({ x: 0, immediate: false })
    },
  })

  return (
    <div className="list-item">
      <div className="background">
        <Heart
          style={{
            color: 'white', fill: isLiking ? 'white' : 'transparent', transition: 'transform 0.3s ease' }}
         />
      </div>
      <animated.div
        {...bind}
        style={{
          transform: transform: x.interpolate(x => `translateX(${x}px)`),
        }}
        className="sliding-pane"
      >
        {children}
      </animated.div>
    </div>
  )
}

Our move callback checks to see if the user has gestured far enough to the like, and updates our isLiked state accordingly. Our heart icon changes appearance in response. But we don’t actually trigger the like event until the gesture has ended in order to give the user the chance to cancel their gesture.

Further enhancements

This gesture can be improved in a few ways:

Ideally we should provide some resistance once the gesture has entered ‘like’ mode.
The heart should move horizontally in response to the gesture.

You can see both of these in the final version:

Examples in the wild

I’ve created a few open source components that respond to gestures which might be useful for learning.

react-gesture-view offers swipeable views that animate left and right.
Sancho-UI offers a number of components which accept gestures, notably sheet. You can view the source here.
React-spring has some absolutely killer examples including the slider that our example is based on.

Got others you want to share? I’d love to see them!

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

Introducing Sancho UI

Ben McMahen — Sat, 13 Apr 2019 18:40:09 +0000

Sancho is an open source, responsive and accessible design system built with React, Typescript and Emotion. View the documentation or check the code on Github.

Images of Julienne.app and Captioner.app, both built with Sancho.

Sancho aims to provide a beautiful, generic set of components that you can make your own.

The primary goal of Sancho’s design is to provide a set of UI components which are beautiful and functional but generic enough to be used in most contexts, and extensible enough to be made your own.

I’ve found that many recent design systems are built with a particular project in mind with a unique, distinctive style, which makes it difficult to use without your work looking like an existing project. Something like Material-UI is really great, but its style is very much identifiable with the Google brand. Bootstrap has always struck me as different in this regard - it provides a beautiful, somewhat generic set of styles and components which work great out of the box but which can easily be altered. It feels like Bootstrap was made for you.

Sancho tries to replicate Bootstrap in this regard. Its design isn’t particularly distinctive and it implements many of my favourite ideas from existing design systems. It’s also meant to be extensible through a combination of theming variables and component composition techniques.

Responsive design is really hard. Sancho makes it easier.

For various reasons, many react based design systems don’t make responsive design a priority. Sancho does its best to make mobile designs and touch interactions as good as possible. This comes out in some of the smaller details.

Sancho provides scroll locking in the appropriate context. Here’s an example of scrolling within a Sheet.

Sancho provides a responsive popover which acts as a regular popover on larger screens, but turns into a bottom sheet on mobile devices.

Sancho’s tabs scroll into view on smaller screens.

The goal is to ensure that Sancho looks and feels as good on touch devices as it does on the desktop, a goal which is often surprisingly and frustratingly difficult to achieve. Using Sancho components will hopefully make your life a bit easier.

Sancho has a dark mode.

Sancho provides a dark mode for all of its components which makes it relatively easy to build a dark and light mode version of your website.

The documentation demonstrates both light and dark mode

But perhaps more importantly, dark and light mode can be utilized at the same time on different portions of your website. This makes it easy to build something like a navigation bar which has a dark background and light themed components and text. Just wrap the relevant elements with the DarkMode component:

import { DarkMode } from 'sancho'

function App() {
  return (
    <div>
      <DarkMode>
        <NavigationBar />
      </DarkMode>
      <Container>
        <MainContent />
      </Container>
    </div>
  )
}

You can see this in action on the toasted-notes website which has a hero with a dark background and light text. Even buttons are subtly altered to provide greater contrast on dark backgrounds.

Sancho is built with Typescript, Emotion and React.

Sancho is fully typed because it’s built with Typescript. This means that your theme is typed which ensures that you only access a value that exists on your theme object.

/** @jsx jsx */
import { jsx } from '@emotion/core'
import { useTheme } from 'sancho'

function App() {
  const theme = useTheme()
  return (
    <div
      css={{
        background: theme.colors.background.tint1,
        fontSize: theme.sizes.giant, // typescript will tell you this doesn't exist
      }}
    >
      Hello world
    </div>
  )
}

I’ve found that using Emotion’s css prop in combination with typescript’s typing and VSCode’s autocomplete largely renders a Box component or something like styled-system unnecessary. Emotion’s css prop also makes it easy to compose styles and alter existing components.

/** @jsx jsx */
import { jsx } from '@emotion/core'
import { Alert, useTheme } from 'sancho'

function MyCustomAlert() {
  const theme = useTheme()
  return (
    <Alert
      title="This Alert has an altered appearance"
      css={{
        maxWidth: '300px',
        '& .Alert__bar': {
          display: 'none',
        },
        '& .Alert__content': {
          padding: theme.spaces.sm,
        },
      }}
    />
  )
}

Sancho supports tree shaking. Bundle only the components that you need.

It’s unlikely that you’ll need to use all of the components provided Sancho. Sancho is fully tree shakable which means that only those components that you use will be included in your final build.

If you import Text and IconArrowRight into a create-react-app bundled application, the final Sancho related build size is 8.4kb minified.

Two open source projects built with Sancho.

Julienne.app is a little app for sharing recipes with family and friends. View the source.

Captioner.app provides a way to create subtitles for videos in your web browser. View the source.

Further resources

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

Using Firebase with React Hooks

Ben McMahen — Sat, 30 Mar 2019 02:50:11 +0000

This tutorial demonstrates the use of hooks in your react application to better integrate firebase authentication and firestore data fetching. Before starting, it’s helpful to have a basic understanding of hooks, firebase authentication and firestore. By the end, we will be building some of the hooks found in our example application, Julienne.app.

Monitoring authentication

Using a combination of hooks and context makes it easy to access user sessions anywhere in your React application. We can store the user session in context, and pass that context to our child components. These components can then make use of hooks to access the session object.

First, create our context.

const userContext = React.createContext({
  user: null,
})

We supply our context with a default value containing a null session object. This will change when we use firebase to monitor changes to our session.

Next, we will create a hook that allows us to access our context.

export const useSession = () => {
  const { user } = useContext(userContext)
  return user
}

Finally, let’s create a hook that monitors the firebase authentication state. This hook will create state which uses a useState callback to determine whether a user session already exists. The callback is a useful way to initialize state with a value only upon the first mount of a componment.

Next, we use an effect which monitors authentication changes. When you trigger a login using one of the many firebase login methods (or you log out), the onChange function will be called with the current authentication state.

Finally, we return our authentication state.

export const useAuth = () => {
  const [state, setState] = React.useState(() => { const user = firebase.auth().currentUser return { initializing: !user, user, } })
  function onChange(user) {
    setState({ initializing: false, user })
  }

  React.useEffect(() => {
    // listen for auth state changes
    const unsubscribe = firebase.auth().onAuthStateChanged(onChange)
    // unsubscribe to the listener when unmounting
    return () => unsubscribe()
  }, [])

  return state
}

We can then use this hook at the top level of our app and use our context provider to supply the user session to child components.

function App() {
  const { initializing, user } = useAuth()
  if (initializing) {
    return <div>Loading</div>
  }

  return (
    <userContext.Provider value={{ user }}> <UserProfile /> </userContext.Provider> )
}

Finally, within child components we can use our useSession hook to gain access to our user session.

function UserProfile() {
  const { user } = useSession() return <div>Hello, {user.displayName}</div>
}

To actually sign in or sign out, you really don’t need to use hooks at all. Simply call firebase.auth().signOut() or the various sign in methods in your event handlers.

Fetching a document

Hooks are useful for monitoring individual document queries using firestore. In this example, we want to fetch a recipe when provided an id. We’ll want to provide our components with error, loading, and recipe state.

function useRecipe(id) {
  // initialize our default state
  const [error, setError] = React.useState(false) const [loading, setLoading] = React.useState(true) const [recipe, setRecipe] = React.useState(null)
  // when the id attribute changes (including mount)
  // subscribe to the recipe document and update
  // our state when it changes.
  useEffect(
    () => {
      const unsubscribe = firebase.firestore().collection('recipes') .doc(id).onSnapshot( doc => { setLoading(false) setRecipe(doc) }, err => { setError(err) } )
      // returning the unsubscribe function will ensure that
      // we unsubscribe from document changes when our id
      // changes to a different value.
      return () => unsubscribe()
    },
    [id]
  )

  return {
    error,
    loading,
    recipe,
  }
}

Fetching a collection

Fetching a collection is very similar, but we instead subscribe to a collection of documents.

function useIngredients(id) {
  const [error, setError] = React.useState(false)
  const [loading, setLoading] = React.useState(true)
  const [ingredients, setIngredients] = React.useState([])

  useEffect(
    () => {
      const unsubscribe = firebase
        .firestore()
        .collection('recipes')
        .doc(id)
        .collection('ingredients') .onSnapshot( snapshot => { const ingredients = [] snapshot.forEach(doc => { ingredients.push(doc) }) setLoading(false) setIngredients(ingredients) }, err => { setError(err) } )

      return () => unsubscribe()
    },
    [id]
  )

  return {
    error,
    loading,
    ingredients,
  }
}

If you plan to use hooks with firebase throughout your application, I recommend checking outreact-firebase-hooks. It provides some useful helpers that allows us to reuse some of the logic that we wrote above.

For an example of a fully functioning app built with Firebase, React, and Typescript, check out Julienne.

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

How to be Introverted and Successfully Self-Promote

Ben McMahen — Tue, 26 Mar 2019 05:33:07 +0000

Being an introverted self-promoter is difficult because everything about self-promotion seems antithetical to your nature. It feels like needlessly exposing yourself to risk. When you say, “hey - look at this cool thing I built!” - people... god forbid, can become aware of your work and they can judge it. And when they judge it, you (mistakingly) think they are implicitly judging you and your abilities. Have you ever read the hacker news comment section? What introvert (indeed, what human) would want to subject themselves to that?

When you’re introverted or shy, you naturally tend to fade into the background. The spotlight is your enemy. You know it’d probably do you some good to be in it, but you kinda hope it just passively finds you amongst the crowd (Yeah, right….). So the introvert tends to passively “like” things on twitter without replying with messages of their own. The introvert tends to lurk on sites like Reddit, sitting back and observing the situation, letting others do the talking.

Honestly, I'm terrible at self-promoting, or networking, or whatever you want to call it.

But I do have a plan. Let me share it with you.

Don’t think of it as self-promotion.

Think of yourself as trying to engage with people, or better yet, as attempting to help people. You built a tool that you find useful? Chances are that at least someone else out there will find it useful too. Even if only two people out of a hundred use it and the rest shit on it, the world is still a better place for those two people.

Make concrete goals that force you to engage more.

You know you have the tendency to lurk so create concrete goals that require you to engage more. Here are a few I’m trying:

1. Instead of just liking a tweet and moving on, attempt to give a thoughtful reply to that tweet especially if you have something nice to say. You love it when people reply to your tweets like this, so why not spread the love?

2. Send a direct message to anyone that follows you on twitter. This idea comes from Harry Stebbings, and it’s a great one:

Every night for 20 mins I send a personal DM to every new follower. I have now sent 16,427 DMs this way. It has led to:

👨‍👨‍👧‍👧 Incredible friendships and discussions with amazing people.

❤️ Incredible community love for @twentyminutevc

💵 $100K+ in sponsors.

Go the extra mile.

— Harry Stebbings (@HarryStebbings) March 17, 2019

People follow you because they’re interested in what you have to say. Reach out and thank them - ask them some questions based upon their profile and follow them back! Do the same when you follow someone. Explain how you value their work, and let them know that you appreciate their opinions.

3. Make a list of social news indexes like hacker news, reddit, and digg (is that still a thing?) and post every single thing you make to them. Don’t make exceptions. Just do it. Force yourself. Remember - even if just two or three people benefit from whatever you post, it’s worth it!

One New Years I came up with the resolution of never turning down an invitation - a resolution that might seem absurd to most people, but really worked wonders for me. I knew I had the tendency to pass on opportunities that I’d later regret, and this resolution forced me to jump on them no matter how reluctant I was. It worked because it was concrete and easily measurable and I knew when I had cheated. Introverts, especially those with social anxiety, tend to let their fears shout out the other parts of their brain in social contexts: you know what’s good for you, but your irrational fears convince you otherwise. These “hacks” make it more difficult for this voice to win.

Go full on with engaging in ways you feel comfortable.

I’m probably not going to be presenting at conferences any time soon, but I do love writing, and blogging is a great outlet for me. These posts are valuable even if no one reads them, in large part by providing a space for me to organize and clarify my own thoughts. To effectively write something you need to really understand it.

So, that’s my plan. Are you an introverted solo dev or entrepreneur? What are your strategies for networking and self-promotion? I’d love to hear them - I need all of the help I can get!

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

The Unique Value of the Tech Generalist

Ben McMahen — Sun, 24 Mar 2019 06:59:52 +0000

Recently Henrik Joreteg tweeted about the difficulty describing the value he brings to a team when no one particular role encompasses his skillset.

Don't know how to describe the role I play on most projects.

It's some mixture of dev, tech lead, solutions architect, UX design, user advocate, and product manager.

I build products.

Do we have to have to slice that into 10 different roles? Can I just be a product developer?

— Henrik Joreteg (@HenrikJoreteg) March 20, 2019

Henrik isn’t alone here. I find myself struggling with the same thing and I know many others do too. I am what you’d call, for lack of better terminology, a generalist. I can design. I can code. I can do frontend and backend. Postgres? Typefaces? Writing copy? Bring it on! I may not be amazing at all of these things, but I’m competent enough to at least get stuff done. So what am I? A “product developer”?

I guess the label doesn’t really matter. What matters more is being able to explain what the generalist brings to the table. And I think that value can be expressed as three primary capacities.

1. The Capacity to do Most Things

The Swiss-army knife is great, especially when in survival mode. And let’s face it, early stage startups are often in survival mode.

The generalist can wear many different hats and do what needs to be done. The value of the generalist at the early startup stage is fairly self-evident and probably least in need of explanation.

2. The Capacity to Learn

The generalist demonstrates the capacity to learn many disparate skillsets which, within the tech world, is important because technology is always changing. (Remember when there was a hot new Javascript library every 4 months?) Anyway, chances are you’ve been put into a situation where you’ve had to learn something out of necessity, and, whether through divine inspiration or repeated banging of head against wall, you’ve managed to at least kludge something together that gets the job done. We, the generalists, are the masters of kludge. But once you kludge enough, you learn to build something that not only works, but leaves you with a bit of pride.

3. The Capacity to Mediate

Much of the expertise in our world is divided amongst specialized experts, and for good reason: to fully understand something we often need to devote resources (our own time and energy) at the expense of other things. We can’t all be Leonardo Da Vinci.

But this comes at a cost. Our categories of expertise can be artificially stiffling and limiting. They can result in biases - a sort of myopia brought on by looking at something too close. Stepping back and being able to look at a problem from multiple perspectives can help shed new light on them, and having people with a holistic view can help mediate between people in these areas of expertise.

The same holds true for web and app development. Consider the value in having a designer who can code:

On a practical level, a designer who can code has the capacity to communicate with programmers. But more fundamentally, a designer who understands the nature of their medium also understands the potential of that medium — the potential for beauty, expression and achievement, and, equally as important, the potential for ugliness and disaster. It’s analogous to the potter who starts with a conception of a pot — an image based upon an understanding of the medium, with all of its various constraints and possibilities — and is able to execute a vision based upon this understanding.

Let’s bring this back to the web. Code is, in many important respects, design. The symptoms of bad code can directly affect the user experience in obvious ways. But design also comes with a cost in terms of programming hours, performance, and added complexity which limits your capacity to change and evolve as a platform. Kevin Gates makes this point when he says that we should ”[t]hink of code complexity as the opposite of a force multiplier. It’s a force diminisher. It imposes a tax on everything you might want to do with your product in the future.” Introducing features comes with a complexity cost. And introducing features costs time and money. Again, as Kevin writes, ”[i]deas are cheap and disposable; code is expensive and persistent.”

Let’s not (sadly) forget about marketing and growth. Good design isn’t just about creating intuitive ux patterns, typefaces and beautiful gradients. It’s about designing a product that people will buy. You typically have your growth team and your product team, often with subtly incompatible aims, with one of these teams winning out (yeah, the growth team) resulting in something like this:

Wait, why did I come to this site again? pic.twitter.com/9rHce97Nvu

— Nicholas C. Zakas (@slicknet) February 18, 2019

Yeah, this is kinda horrible and can be avoided with good communication between teams. The generalist can help mediate these subtly incongruous goals while creating a solution that benefits both product and user.

Calling all Webmasters

This is how I’d explain my value. Are you a generalist? How would you explain your value? What should we call ourselves? Is it time we brought back the “Web Master”?

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

Writing your CSS with Emotion

Ben McMahen — Fri, 01 Mar 2019 21:53:20 +0000

[Edit] Styled-components also supports the css prop! So consider this more of an article about comparing two apis - the styled api vs the css api.

I have written css for the web in just about every way imaginable. I’ve used css modules, preprocessors including Sass, Less, and Stylus, BEM, functional css (using Tachyons), and I’ve used numerous CSS-in-JS libraries including Styled-components, and react-native stylesheets. I’ve tried all of this, and using Emotion’s css prop is easily my favourite. I’ll try to explain why.

Emotion vs Styled-components

Let’s assume that you’re already on the CSS-in-JS bandwagon. If you’re not, it’s worth perusing the many great articles and videos about the benefits of writing css in Javascript.

My main task here is to argue that using Emotion is the best library with which to style your apps. In truth, Emotion shares much with the other behomoth in the CSS-in-JS realm, Styled-components. It even exposes a styled api that basically mimics how styled-components works. But in comparing the two libraries, I’m really comparing two distinct options for styling your components.

One is the styled-components way:

import styled from 'styled-components'

const Button = styled.button` 
  background: #08e; 
  color: white; 
  padding: 6px 10px; 
  border: none;
`

function Example() {
  return (
    <div>
      <Button>Hello world</Button>
    </div>
  )
}

Styled-components uses the styled.button style API combined with template literals to create buttons with styles. You can see why it’s popular. With examples like this, it’s a beautiful API.

In contrast, with Emotion we can add styles to an element using the css prop much as you’d use the style prop.

/** @jsx jsx */
import { css, jsx } from '@emotion/core'

const Button = props => (
  <button
    css={{ 
      background: '#08e', 
      color: 'white', 
      padding: '6px 10px', 
      border: 'none', 
    }}
    {...props}
  />
)

function Example() {
  return (
    <div>
      <Button>Hello world</Button>
    </div>
  )
}

On first glance, the styled-component example seems more elegant. But I’ve found that over the long run, I generally prefer the css style api for the following reasons:

You’re still writing regular React components.

Especially when working with typescript, I consider this beneficial. You type a Button component just as you would a regular React component, allowing you to clearly specify which props are accepted. As a result, you’re less likely to pollute your dom with odd attributes—a problem I found common when passing custom attributes to styled components.

Object styles are easier to work with.

When working with typescript, I love that all of my css is typechecked and provides robust autocompletion. And I generally find it easier to insert theme variables into objects instead of using the ${theme.color.red} style notation. The small downside to objects is that they are slightly more cumbersome to write and aren’t easily copied from browsers.

Naming things is hard. And I’m lazy.

When working with styled-components you generally need to create names for components with distinct styles. This results in many components which lack obvious semantic importance which nevertheless require distinct names. Naming these components with a meaningful descriptor can be tough. Furthermore, the boilerplate often feels burdensome when applying small custom styles, such as altering margins or padding. So, because I’m lazy, I find myself often resorting to using the style prop for quick adjustments.

But using the css prop avoids these pitfalls, while still providing the opportunity to wrap styles into a component if it’s worth reusing and semantically meaningful.

function Example() {
  return (
    <div
      css={{
        margin: theme.spacing.sm,
        padding: theme.spacing.sm,
      }}
    >
      <Button variant="primary">Hi there</Button>
    </div>
  )
}

You colocate styles with elements.

With the css prop, what you see is what you get. It’s a small point, but not having to scroll away from an element to find your style definition really improves my workflow. It feels more efficient and keeps me in the flow when writing my components. Need to delete an element? There’s no need to hunt down the orphaned style definition.

Composition is dead easy.

Consider our Button component. What if we want to provide a margin to it?

function Example() {
  return (
    <>
      <Button css={{ marginRight: '1rem' }}>Cancel</Button> 
      <Button variant="primary">Save</Button>
    </>
  )
}

This passes the styles defined in our example to the Button element and composes the styles for us, applying the custom margin.

Both are great, but I choose Emotion

Styled-components is a wonderful tool and combined with something like styled-system you can get the benefits of functional style css which can alleviate some of the naming issues. But I’ve found that using the css prop, especially with typescript, reduces the need for something like styled-system and generally provides the most flexible means of writing your styles in Javascript.

Suggested links :

Emotion.sh

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

Three Ways to use Hooks to Build Better React Components

Ben McMahen — Fri, 22 Feb 2019 22:56:40 +0000

This article provides three ways in which you can replace various old React composition patterns with hooks to build simpler, more reusable components. Before starting, it helps to have some experience with various patterns related to component composition, including making use of children, using render props, higher order components, and cloning elements. And it helps if you have an introductory understanding of hooks.

Tip 1: Replace cloneElement with hooks

You can often replace instances of cloneElement, higher order components, or render props with hooks.

The motivation of using one of the above techniques is almost always to provide either some contextual information to child components or to expose some additional logic to components. React's cloneElement function is probably the oldest means to achieve this end, but it's always had some downsides: 1) It's usage is dependent on the child being of the correct type. 2) It can overrwrite props, necessitating that you wrap potential props to ensure that each one is applied correctly. 3) It's difficult to properly type child components when using something like Typescript.

Let's explore a better solution using hooks. Let's say we want to make a child component aware of which parent it's in when developing a table so that we can use the correct tagName, either an td or th. Consider the cloneElement way to achieve this:

const TableHead = ({ children }) => {
  return (
    <thead>
      {React.cloneElement(children, {
        parent: 'TableHead',
      })}
    </thead>
  )
}

const TableBody = ({ children }) => {
  return (
    <tbody>
      {React.cloneElement(children, {
        parent: 'TableBody',
      })}
    </tbody>
  )
}

const TableCell = ({ parent, children }) => {
  const Component = parent === 'TableHead' ? 'th' : 'td'
  return <Component>{children}</Component>
}

This works decently enough. We can create a table and the correct tagNames are used in each case.

const Table = () => (
  <table>
    <TableHead>
      <TableCell>Name</TableCell>
      <TableCell>Age</TableCell>
    </TableHead>
    <TableBody>
      <TableCell>Ben McMahen</TableCell>
      <TableCell>Thirty-something</TableCell>
    </TableBody>
  </table>
)

We can provide a more flexible solution using hooks and context. Let's rewrite our components to demonstrate:

const SectionContext = React.createContext({ parent: 'TableHead' })

const TableHead = ({ children }) => {
  return (
    <thead>
      <SectionContext.Provider value={{ parent: 'TableHead' }}>
        {children}
      </SectionContext.Provider>
    </thead>
  )
}

const TableBody = ({ children }) => {
  return (
    <tbody>
      <SectionContext.Provider value={{ parent: 'TableBody' }}>
        {children}
      </SectionContext.Provider>
    </tbody>
  )
}

const TableCell = ({ children }) => {
  const { parent } = React.useContext(SectionContext)
  const Component = parent === 'TableHead' ? 'th' : 'td'
  return <Component>{children}</Component>
}

This is a more flexible solution because it doesn't depend on TableCell being a direct descendent of either TableHead or TableBody. It's also great if you're using typescript because it doesn't polute your TableCell props with props that are provided by the parent component.

Tip 2: Bind elements to refs

Return a bind function from your hooks to make reference to dom elements.

I first came across this pattern in react-spring and I've used it a ton since. Consider cases where you want to create reusable functionality which makes reference a particular dom element, such as measuring dom elements or focusing them. In my case, I recently needed to create a reusable focus manager that binds to a particular element and either focuses an element if it's showing or returns focus if it's not. Focus trap is a great tool for helping us here. Let's start with a basic hook skeleton.

export function useFocusElement(showing, options = {}) {
  const elementRef = React.useRef(null)

  return {
    bind: { ref: elementRef },
  }
}

So yeah, this doesn't do much. It returns a bind object which includes a reference to our elementRef. This will allow us to create a reference to any dom element that we want to focus. The showing argument will be used to determine if we should assign focus to the elementRef or return it to the element originally focused. We can use the hook as follows:

const Popover = () => {
  const [showing, setShowing] = React.useState(false)
  const bind = useFocusElement(showing)
  return <div {...bind}>Popover!</div>
}

Let's implement the rest of the hook to make use of focus trap:

export function useFocusElement(showing, options = {}) {
  const elementRef = React.useRef(null)
  const trapRef = React.useRef(null)

  function focusElement() {
    const trap = createFocusTrap(elementRef.current, {
      escapeDeactivates: false,
      clickOutsideDeactivates: false,
      fallbackFocus: '[tabindex="-1"]',
      ...options,
    })

    trapRef.current = trap
    trap.activate()
  }

  function focusTrigger() {
    trapRef.current.deactivate()
  }

  React.useEffect(
    () => {
      if (showing) focusElement()
      else focusTrigger()
    },
    [showing]
  )

  return {
    bind: { ref: elementRef },
  }
}

So here's what's happening: We create two refs: our elementRef is binding to our popup menu, while our trapRef is referencing our focus trap instantiation. When the showing prop changes, we either focus our elementRef or we return focus to the trigger element.

This hook doesn't create any additional dom elements and it's incredibly easy to reuse within different components when you need to manage focus for accessibility reasons. I've used it in a popover, modal, and dropdown menu. I recommend being consistent in using a bind object which includes things like ref but which can also include additional functions such as onKeyDown, onMouseOver, etc.

You can see the full implementation of the useFocus hook in sancho-ui, and see how it's used in the Popover implementation.

Tip 3: useState takes a callback

When using useState with a callback, the callback is run only on the initial mount. This is useful for running expensive computations. Compare these two examples:

let counter = 0

function Component() {
  const [number] = useState(counter++)
  return <div>{number}</div>
}

With this example, any time our Component updates our counter will be incremented. Note that this will not update our number state, since default state values can only ever be set once on the initial mount of the component.

Let's convert useState to use a callback.

let counter = 0

function Component() {
  const [number] = useState(() => counter++)
  return <div>{number}</div>
}

This will only increment our uid once during the entire lifespan of that component, even if it rerenders. Like the above example, our number will remain constant.

The sandbox below demonstrates these differences:

(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)

Forem: Ben McMahen

A Beginner's Guide to Generics in Typescript

An Introduction to SwiftUI for React Developers

Using state in Swift UI

Passing props to components

Updating parent state in child views using binding

Other React Design Patterns in SwiftUI

React design patterns in SwiftUI

Advanced Gestures on the Web - iOS in React

A Beginners Guide to using Typescript with React

Your basic react component with typescript

Extending standard HTML attributes

Handling events

Using string literals

Using Generics with your react components

Typing hooks

Typing a reducer

Using typeof and keyof to type component variants

Building React Components with Gesture Support

The basic component layout

Adding drag gestures with react-gesture-responder.

Using react-spring for better control and performance.

Determining when the user has ‘liked’ the list item.

Further enhancements

Examples in the wild

Introducing Sancho UI

Sancho aims to provide a beautiful, generic set of components that you can make your own.

Responsive design is really hard. Sancho makes it easier.

Sancho has a dark mode.

Sancho is built with Typescript, Emotion and React.

Sancho supports tree shaking. Bundle only the components that you need.

Two open source projects built with Sancho.

Further resources

Using Firebase with React Hooks

Monitoring authentication

Fetching a document

Fetching a collection

How to be Introverted and Successfully Self-Promote

Don’t think of it as self-promotion.

Make concrete goals that force you to engage more.

Go full on with engaging in ways you feel comfortable.

The Unique Value of the Tech Generalist

1. The Capacity to do Most Things

2. The Capacity to Learn

3. The Capacity to Mediate

Calling all Webmasters

Writing your CSS with Emotion

Emotion vs Styled-components

You’re still writing regular React components.

Object styles are easier to work with.

Naming things is hard. And I’m lazy.

You colocate styles with elements.

Composition is dead easy.

Both are great, but I choose Emotion

Three Ways to use Hooks to Build Better React Components

Tip 1: Replace cloneElement with hooks

Tip 2: Bind elements to refs

Tip 3: useState takes a callback

Using `typeof` and `keyof` to type component variants