The Hierarchy (for React apps)

gistfile1.txt

A React app can be split into a number of different types of functions and components, where *each type can depend only on the types above it in the hierarchy*.

This makes gives you a way to split up components and functions over your filesystem. It also helps you to keep components from growing too large, and encourages practices that make testing easier.

```
types (TypeScript typings)
  ^
utils (plain javascript functions)
  ^
contexts (React context, and provider components)
  ^
controls (
  components with no styles,
  that are used to build DOM,
  and have a render function.
  controls can't provide context to the app, but can provide it to other controls
)
  ^
views (
  components primarily concerned with presentation.
  data can be fed in via props or context.
  should avoid exporting context, or having DOM interaction code.
  components that import from a context file other than `AppContext` should be nested in a directory named after that context file.
)
  ^
containers (
  code that is used across multiple screens,
  that handles data and feeds it to views and/or controls,
  generally doesn't add any styles, but is composed of components that do
)
  ^
screens (
  routes,
  content for those routes,
  feeds data into app components, etc.
)
```

*(Then, you probably want a separate store where, which the screens can depend on, but nothing else can...)*

Hi James, I know there is no "right way" of structuring a React App as they all have different focuses, but I was wondering why this is (subtly) different to your CRUV post? Which wasnt that long ago.

Thanks, Lee (@lskiuk)