Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
The Hierarchy (for React apps)
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...)*
@lski

This comment has been minimized.

Copy link

lski commented Mar 2, 2019

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.