Sleep Data Visualization Demonstration

Technologies Used

This project was started with Ignite from Infinite Red as it provides generators to rapidly build and hook up components, screens, and more. It also provides some solid practices around project organization and optimizations for quicker debugging.

Currently includes (from Infinite Red boilerplate):

React Native
React Navigation
MobX State Tree
TypeScript
and more!

Additonal Libraries

react-native-svg-charts - for simple visualizations
date-fns - for date formatting and parsing

Quick Start

Demonstration:

Launching Dev

This project is currently not configured for production builds of the application. As such you will need to follow a few steps to get up and running:

set up your development environment via the React Native docs.
install yarn.
set up a simulator/emulator or on device
install dependencies: yarn install
launch the application: yarn android or yarn ios

If you want to see more about the inner workings, this is hooked up with Reactotron in which you can explore some of the logging and state management.

For Reference

Some things to note in this project:

sleep stages are mapped such (they currently lack labels):
- out = bright orange (1)
- awake = orange (0)
- light = green (-1)
- deep = blue (-2)

Reflections

The core of the application works and demonstrates competency, however, there are certainly some things I'd love to do to it that I deprioritized due to time constraints:

clean up date formatting for stages
fix the Scrollview for sleep stages charts or switch to a Flatlist
add decorators with the timeseries data
add labels for the stages (start time, finish time are already there)
add axis labels for stages (stages with colors for the y-axis and time window for the x-axis)
add session length visually
fix and add tests for complete coverage
clean up the storybooks to make components easily explorable

Time spent on project: 12 hrs (includes research, design, a few environment issues, and implementation)

Follow-Up Critique

clean up the conditionals that can be improved with optional-chaining

// verbose
const hasTitle = title && title.length > 1
// concise
const hasTitle = title?.length > 1

fix MST store type-safety, a few default to any
- strategy: enable strict-mode in linter (not allowing any type) and resolve errors
fix types for stage-chart.tsx to minimize type-based errors and improve DX (dev experience)
migrate styles to use StyleSheet or similar creation patterns removing the need to use ramda to merge styles
- see example in interval-screen.tsx
in most cases, async await statements could be within a try/catch block avoiding less readable promise-chaining
async-image could have a cleaner image swap for placeholder or other animated effect with a simple shape
examples of the styles with an updated pattern:

<Component style={[style,
  styles.placeholder, // this uses the StyleSheet pattern described above for improved type-safety
  {
    backgroundColor: placeholderColor,
    opacity: placeholderOpacity,
    transform: [{ scale: placeholderScale }],
}]}/>

add proper type-safety to api.ts for getIntervals and getUsers
abstract creation of animated value to a custom hook useAnimatedValue used often in useImplosionExplosion as it's a common pattern for animation
update the project so it can run properly in newer environments. It currently fails to compile on newer versions of iOS and Node.
enforce using import type patterns with lint-rules to safeguard against edge-case problems and improved optimizations
- see example of usage in interval-store.ts
- see a decent write-up/summary of benefits on stackoverflow with reference to documentation
migrate away from index.ts export modules for root folders as it can lead to import require cycles.
- potential strategy: employ absolute path import aliases to reduce messy nesting and improve readability (see example from nextjs docs)
- alternative strategy: move common imports into private modules that are managed with your package manager

Exploring the Project

The Ignite Bowser boilerplate project's structure will look similar to this:

ignite-project
├── app
│   ├── components
│   ├── i18n
│   ├── utils
│   ├── models
│   ├── navigation
│   ├── screens
│   ├── services
│   ├── theme
│   ├── app.tsx
├── storybook
│   ├── views
│   ├── index.ts
│   ├── storybook-registry.ts
│   ├── storybook.ts
├── test
│   ├── __snapshots__
│   ├── storyshots.test.ts.snap
│   ├── mock-i18n.ts
│   ├── mock-reactotron.ts
│   ├── setup.ts
│   ├── storyshots.test.ts
├── README.md
├── android
│   ├── app
│   ├── build.gradle
│   ├── gradle
│   ├── gradle.properties
│   ├── gradlew
│   ├── gradlew.bat
│   ├── keystores
│   └── settings.gradle
├── ignite
│   ├── ignite.json
│   └── plugins
├── index.js
├── ios
│   ├── IgniteProject
│   ├── IgniteProject-tvOS
│   ├── IgniteProject-tvOSTests
│   ├── IgniteProject.xcodeproj
│   └── IgniteProjectTests
├── .env
└── package.json

./app directory

Included in an Ignite boilerplate project is the app directory. This is a directory you would normally have to create when using vanilla React Native.

The inside of the src directory looks similar to the following:

app
│── components
│── i18n
├── models
├── navigation
├── screens
├── services
├── theme
├── utils
└── app.tsx

components This is where your React components will live. Each component will have a directory containing the .tsx file, along with a story file, and optionally .presets, and .props files for larger components. The app will come with some commonly used components like Button.

i18n This is where your translations will live if you are using react-native-i18n.

models This is where your app's models will live. Each model has a directory which will contain the mobx-state-tree model file, test file, and any other supporting files like actions, types, etc.

navigation This is where your react-navigation navigators will live.

screens This is where your screen components will live. A screen is a React component which will take up the entire screen and be part of the navigation hierarchy. Each screen will have a directory containing the .tsx file, along with any assets or other helper files.

services Any services that interface with the outside world will live here (think REST APIs, Push Notifications, etc.).

theme Here lives the theme for your application, including spacing, colors, and typography.

utils This is a great place to put miscellaneous helpers and utilities. Things like date helpers, formatters, etc. are often found here. However, it should only be used for things that are truely shared across your application. If a helper or utility is only used by a specific component or model, consider co-locating your helper with that component or model.

app.tsx This is the entry point to your app. This is where you will find the main App component which renders the rest of the application. This is also where you will specify whether you want to run the app in storybook mode.

./ignite directory

The ignite directory stores all things Ignite, including CLI and boilerplate items. Here you will find generators, plugins and examples to help you get started with React Native.

./storybook directory

This is where your stories will be registered and where the Storybook configs will live

./test directory

This directory will hold your Jest configs and mocks, as well as your storyshots test file. This is a file that contains the snapshots of all your component storybooks.

Running Storybook

From the command line in your generated app's root directory, enter yarn run storybook This starts up the storybook server.

In index.js, change SHOW_STORYBOOK to true and reload the app. For Visual Studio Code users, there is a handy extension that makes it easy to load Storybook use cases into a running emulator via tapping on items in the editor sidebar. Install the React Native Storybook extension by Orta, hit cmd + shift + P and select "Reconnect Storybook to VSCode". Expand the STORYBOOK section in the sidebar to see all use cases for components that have .story.tsx files in their directories.

pixelknitter / DataVisualization