Why React Is a Game Changer For UI

React may be a library for building front-end web applications but the concepts it introduces are exciting and I’d love to see them applied to native user interface libraries.

In this post we’ll be comparing the way React unifies behaviour and layout with the way traditional user interface libraries separate them, and the conceptual simplification this brings.

The Traditional Way

It is often the case in user interface libraries that entire chunks of the layout are defined in single files, detached from the code that controls them.

ToDoList.layout

<VerticalLayout id="layout">
  <ListBox id="myList"/>
  <Label id="helpLabel" text="Click the add button!"/>
  <Button id="addButton" onClick="addButtonClicked"/>
<VerticalLayout/>

ToDoList.class

class ToDoList of Widget {
  constructor() {
    setLayoutFromFile("ToDoList.layout")
  }

  addButtonClicked(){
    layout.hide(helpLabel)
    myList.addItem()
  }
}

This separation requires that the developer expend extra effort to understand how individual classes impact the displayed layout at any given time.

In this paradigm behaviour and layout are very far from each other, meaning that additional software must be used to navigate and stitch together the sprawling files. This is to say that WYSIWYG editors in this instance are a symptom, not a solution.

Some of these problems could be addressed by defining the layout with the behaviour code, but this comes at the cost of the clarity provided by the hierarchical approach found in XML-like languages. Below you can see how meaning is lost with the flattening of the code.

ToDoList.class

class ToDoList of Widget {
  constructor() {
    myList = ListBox()
    addButton = Button("Add")
    helpLabel = Label("Click the add button!")
    layout = VerticalLayout()
    layout.add(myList)
    layout.add(addButton)
    layout.add(helpLabel)
    setLayout(layout)
  }

  addButtonClicked() {
    layout.hide(helpLabel)
    myList.addItem()
  }
}

These libraries also splinter the definition of an interface across a class, potentially occurring at any point during the event loop, making it difficult to change the existing interface without being aware of its current state. Out of necessity some projects will often end up uniting user interface updates under a single method, similar to React.

The New Way

React on the other hand makes it very easy to see where your user interface begins and ends. It does this by splitting parts of the user interface into components that can be represented in a nested structure with your code and uniting all changes under one method, which cannot itself affect the state of the component.

ToDoList.class

class ToDoList of Widget {
  constructor() {
    state.labelHidden = false
    state.listItems = []
  }

  addButtonClicked() {
    state.labelHidden = true
    state.listItems += ListItem()
  }

  render() {
    return <VerticalLayout id="layout">
      <ListBox id="myList" items=state.listItems/>
        if state.labelHidden {
          <Label id="helpLabel" text="Click the add button!"/>
        }
      <Button id="addButton" onClick="addButtonClicked"/>
    <VerticalLayout/>
  }
}

Rendering is done in the render() method, this ensures that any runtime changes made to the user interface are done in one place, rather than events being able to modify the layout directly. This means that you do not need to keep track of components, avoiding bugs caused by irrelevant elements of the layout persisting. Additionally, functionality attached to the layout is defined very close to the user interface itself, making it easy to navigate between the user interface and the associated functionality.

React Native is sometimes dismissed as a fad fueled by the prevalence of Javascript but this simplistic view overlooks the clear demand for a better way to build user interfaces and for the time being at least, it is React Native that is fulfilling that demand.

About the Author