Skip to content

Instantly share code, notes, and snippets.

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 (
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...)*
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