|
| 1 | +# React Data List |
| 2 | + |
| 3 | +A library for composing data arrays using React components. |
| 4 | + |
| 5 | +## Why? |
| 6 | + |
| 7 | +Universal List is an API for composing together lists. |
| 8 | + |
| 9 | +In React Native world, virtualized lists are modelled with a flat array of data, along with a render function that describes how to render items. Most of our screens tend to be represented virtualized lists. It's a pillar to how we build. |
| 10 | + |
| 11 | +However, building this data array can be really difficult. The straightforward approach is to simply have a dataFetchable that's the result of a single useNexusSelector call. However quickly becomes a problem when you want to have granular control over loading states (e.g. if we fail to load a single notification then don't poison the entire fetchable) or especially when you want to compose familiar data & render logic across screens (e.g. task picker items on the record detail page). When you need to solve both of those problems you quickly end up in a real mess with data selectors that are hundreds of lines long and not approachable. |
| 12 | + |
| 13 | +Universal List allows you to model the creation of this data array in React JSX, encouraging the use of Suspense and Error Boundaries to achieve the behaviors you want. Nexus has first-class support for these wider React concepts, so the ergonomics are quite nice. |
| 14 | + |
| 15 | +## How does it work? |
| 16 | + |
| 17 | +There are two main concepts: **row** and **renderer**. |
| 18 | +A **row** syncs some data and a render function to the list. The universal list then processes this into an aggregated data array, render function and other typical list functions. These then get passed into a renderer which takes the Universal List format and translates it into inputs for some list component, like FlashList. We refer to the item data that a row syncs as its **descriptor** |
| 19 | + |
| 20 | +## Release Process |
| 21 | + |
| 22 | +This repo uses **Changesets** for versioning and **GitHub Actions** for automated publishing. |
| 23 | + |
| 24 | +### 1. Create Changesets for Changes |
| 25 | + |
| 26 | +```bash |
| 27 | +# Generate a changeset for your changes |
| 28 | +bunx changeset |
| 29 | +``` |
| 30 | + |
| 31 | +- Select which packages are affected by your changes |
| 32 | +- Choose the appropriate semantic version bump (patch, minor, major) |
| 33 | +- Write a descriptive summary of the changes |
| 34 | +- Commit the generated changeset file in `.changeset/` |
| 35 | + |
| 36 | +### 2. Automated Version Management |
| 37 | + |
| 38 | +When you push to the `master` branch, the GitHub Action will: |
| 39 | + |
| 40 | +- **Create a Release PR**: If there are pending changesets, it creates a "Version Packages" PR with updated version numbers, CHANGELOGs, and consumed changeset files |
| 41 | + |
| 42 | +### 3. Release Publication |
| 43 | + |
| 44 | +When the "Version Packages" PR is merged: |
| 45 | + |
| 46 | +- **Automated Build**: Builds only packages using `bun run build-release` |
| 47 | +- **Automated Publishing**: Publishes updated packages to NPM via `changeset publish` |
| 48 | +- **Git Tagging**: Creates appropriate git tags for the released versions |
| 49 | + |
| 50 | +### Manual Release (if needed) |
| 51 | + |
| 52 | +```bash |
| 53 | +# 1. Create changesets for changes |
| 54 | +bunx changeset |
| 55 | + |
| 56 | +# 2. Version packages (updates versions + CHANGELOGs) |
| 57 | +bun run changeset-version |
| 58 | + |
| 59 | +# 3. Build and publish |
| 60 | +bun run changeset-publish |
| 61 | +``` |
0 commit comments