# on-update

> on-update

Latest version **2.0.0** (published 2016-04-20) · MIT license · 0 weekly downloads

## Install

```sh
npm install on-update
pnpm add on-update
yarn add on-update
bun add on-update
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 2.0.0 |
| Published | 2016-04-20 |
| First published | 2015-11-23 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Node | >=5.0.0 |
| Dependencies | 1 |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Author | Luis Carli |
| Maintainers | luiscarli |

## Links

- npm: https://www.npmjs.com/package/on-update
- Repository: https://github.com/luiscarli/on-update
- Homepage: https://github.com/luiscarli/on-update#readme
- Issues: https://github.com/luiscarli/on-update/issues
- npm.io page: https://npm.io/package/on-update

## Dependencies (1)

- [lodash](https://npm.io/package/lodash.md) ^4.0.0

## Recent versions

- 2.0.0 (latest) — 2016-04-20
- 1.3.1 — 2016-04-08
- 1.3.0 — 2016-02-11
- 1.2.2 — 2016-02-08
- 1.2.1 — 2016-01-29
- 1.2.0 — 2016-01-29
- 1.1.1 — 2016-01-03
- 1.1.0 — 2015-12-22
- 1.0.2 — 2015-12-10
- 1.0.1 — 2015-11-23

## README

## onUpdate

[![Build Status](https://travis-ci.org/luiscarli/on-update.svg?branch=master)](https://travis-ci.org/luiscarli/display)

```bash
$ npm i on-update --save
```

The onUpdate is a pattern for state flow between React components.

It defines a contract for data to bubble up the render tree, and update the root state object, without the need of extra libraries and imports. It puts the logic for updating the domain data in response to UI interaction into the React components, in parallel with the logic that does the opposite process, maps the domain data into UI elements (the render function).

This makes the data flow explicit and localized into self sustained components, it also allows for reusable components that are not dependent of other data management libraries, like flux, redux, etc.

React components can be understood as functions that map the data from the domain into interactive UI elements, each component receives data as `props` and returns UI elements (or other components that will ultimately return UI elements). The render function of a component contains the main logic for executing this mapping.

Interactions on the UI elements leads to change in the domain data, the modified domain data when rendered generates a new UI which is the result of the user interaction. The problem in React applications is how to architecture the code to solve the update of the application domain data in response to UI interaction in a way that is resilient, understandable and scalable.

Libraries like flux and redux define specific methods for transforming a centralized state object in response to UI interaction. We advocate here that's possible to achieve the same objectives as those libraries with pure React components.

### onUpdate Data Flow

Functional React components map the data they receive to UI elements. Components are broken into sub components for managing complexity, readability and reusability; each component should be focused into solving the relation between the properties they receive and the components and elements they return.

With the onUpdate pattern, the data for the application is hold by the root component, only transient state should be hold by other components of the application, when the data changes on the top level component it flows down and the components are re-rendered accordingly.

Interactions on leaf components should trigger callbacks that bubbles up to the root component to change its domain data. This flow is solved here on a **component level**, *each component needs to handle both the mapping from his props to the children it renders as also the update of his own props according to the update of the props of his children*.

When an interaction callback occurs (like onClick, onMouseEnter, etc.) the component calls his `props.onUpdate` method with an object containing an updated version of his own `props`, according to the result of the interaction.

A parent component may receive an onUpdate call from any of its children with their updated `props`, the parent component will then create a new object with the update version of his `props` according to the `props` sent by his child onUpdate call. He will then call his own `props.onUpdate` passing up his updated `props`.

This pattern continue up the component tree, as each component remaps the updates of its child `props` back to an update of its own `props`. When the bubble up reaches the root component, and updates the centralized state object, it then triggers a re-render of the components with the updated data.

With this pattern each component contains the full logic of a specific part of the problem that he's solving in a application. The problem of mapping its received data into children components, and handling the update of his `props` according to the update of its children `props`.

When you add inline style and a theme property to the mix, you get a component that's fully self-sustained and reusable across projects and applications, without the need of any extra library or bootstrap.

Also, any part of the data flow of the application can be understood by looking at two files: the parent and the children component. By following this pattern, the tree structure formed by the components of a well developed application can work as a map that explain how the domain data unfolds into the UI elements, and also the opposite, how the UI elements go into updating the domain data.

### Basic Example

```jsx
import React, {PropTypes} from 'react'
import _ from 'lodash'
import {Block} from 'react-display'

export const handleAnnotationUpdate = (props, annotationProps) => {
  props.onUpdate({
    ...props,
    text: annotationProps.text,
  })
}

const ExampleComponent = props => (
  <Block>
    <Annotation
      text={props.text}
      onUpdate={_.partial(handleAnnotationUpdate, props)}
    />
  </Block>
)

ExampleComponent.propTypes = {
  onUpdate: PropTypes.func,
  text: PropTypes.string.isRequired,
}

export default ExampleComponent
```

### Helper

During development it's possible to use the `stateHOC` wrapper helper.

```jsx
import {stateHOC} from 'on-update'
// component definition
export default stateHOC(ExampleComponent)
```

The wrapper extends the `props' passed to the component with an `onUpdate` method, when it's called the props are stored as `state` on the wrapper and the component is re-rendered with the new `props`.

This helps during the development of new components, as the flow up of new data can be done incrementally from bottom up.

---
_Source: https://npm.io/package/on-update · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._