Dan Abramov Style Guide
Overview
Dan Abramov is the co-creator of Redux, Create React App, and a member of the React core team. His philosophy emphasizes predictable state, composition, and building tools that make developers more productive.
Core Philosophy
"Redux is not the answer to all state management. It's one tool in the toolbox."
"The best code is the code that doesn't exist."
"Make impossible states impossible."
Abramov believes in making code predictable and debuggable, using the right level of abstraction, and prioritizing developer experience.
Design Principles
- Predictability: State changes should be predictable and traceable.
- Composition: Build complex from simple, not through inheritance.
- Explicit Over Magic: Prefer verbose clarity over clever brevity.
- Developer Experience: Tools should help developers, not fight them.
When Writing Code
Always
- Keep state as flat as possible
- Make state changes predictable and traceable
- Use composition to build complex components
- Colocate state with components that need it
- Write components that are easy to test
- Think about error boundaries
Never
- Mutate state directly
- Put everything in global state
- Use inheritance for component reuse
- Create deeply nested state structures
- Ignore render performance in lists
- Swallow errors silently
Prefer
- Local state over global when possible
- Hooks over class components
- Function composition over inheritance
- Explicit data flow over prop drilling solutions
- Pure functions for state updates
- Custom hooks for reusable logic
Code Patterns
Component Composition
// BAD: Prop drilling and inheritance thinking
function App() {
return (
<Layout
header={<Header user={user} onLogout={logout} />}
sidebar={<Sidebar items={items} selected={selected} onSelect={select} />}
content={<Content data={data} user={user} />}
/>
);
}
// GOOD: Composition with children
function App() {
return (
<Layout>
<Header>
<UserMenu user={user} onLogout={logout} />
</Header>
<Sidebar>
<Navigation items={items} selected={selected} onSelect={select} />
</Sidebar>
<Content>
<Dashboard data={data} />
</Content>
</Layout>
);
}
// Compound Components Pattern
function Tabs({ children, defaultIndex = 0 }) {
const [activeIndex, setActiveIndex] = useState(defaultIndex);
return (
<TabsContext.Provider value={{ activeIndex, setActiveIndex }}>
{children}
</TabsContext.Provider>
);
}
Tabs.List = function TabList({ children }) {
return <div role="tablist">{children}</div>;
};
Tabs.Tab = function Tab({ index, children }) {
const { activeIndex, setActiveIndex } = useContext(TabsContext);
return (
<button
role="tab"
aria-selected={activeIndex === index}
onClick={() => setActiveIndex(index)}
>
{children}
</button>
);
};
Tabs.Panels = function TabPanels({ children }) {
const { activeIndex } = useContext(TabsContext);
return Children.toArray(children)[activeIndex];
};
// Usage - composable and flexible
<Tabs defaultIndex={0}>
<Tabs.List>
<Tabs.Tab index={0}>First</Tabs.Tab>
<Tabs.Tab index={1}>Second</Tabs.Tab>
</Tabs.List>
<Tabs.Panels>
<Panel>First content</Panel>
<Panel>Second content</Panel>
</Tabs.Panels>
</Tabs>Custom Hooks for Logic Reuse
// Extract reusable logic into custom hooks
function useLocalStorage(key, initialValue) {
const [storedValue, setStoredValue] = useState(() => {
try {
const item = window.localStorage.getItem(key);
return item ? JSON.parse(item) : initialValue;
} catch (error) {
console.error(error);
return initialValue;
}
});
const setValue = useCallback((value) => {
try {
const valueToStore = value instanceof Function
? value(storedValue)
: value;
setStoredValue(valueToStore);
window.localStorage.setItem(key, JSON.stringify(valueToStore));
} catch (error) {
console.error(error);
}
}, [key, storedValue]);
return [storedValue, setValue];
}
// Async data fetching hook
function useAsync(asyncFunction, immediate = true) {
const [status, setStatus] = useState('idle');
const [value, setValue] = useState(null);
const [error, setError] = useState(null);
const execute = useCallback(async () => {
setStatus('pending');
setValue(null);
setError(null);
try {
const response = await asyncFunction();
setValue(response);
setStatus('success');
} catch (error) {
setError(error);
setStatus('error');
}
}, [asyncFunction]);
useEffect(() => {
if (immediate) {
execute();
}
}, [execute, immediate]);
return { execute, status, value, error };
}State Management Patterns
// Pattern 1: Colocate state
// State should live as close to where it's used as possible
// BAD: Lifting state too high
function App() {
const [searchQuery, setSearchQuery] = useState('');
const [results, setResults] = useState([]);
// ... passed down through many layers
}
// GOOD: State lives where it's used
function SearchComponent() {
const [searchQuery, setSearchQuery] = useState('');
const [results, setResults] = useState([]);
// Only this component cares about search
}
// Pattern 2: Reducer for complex state
function reducer(state, action) {
switch (action.type) {
case 'FETCH_START':
return { ...state, loading: true, error: null };
case 'FETCH_SUCCESS':
return { ...state, loading: false, data: action.payload };
case 'FETCH_ERROR':
return { ...state, loading: false, error: action.payload };
default:
throw new Error(`Unknown action: ${action.type}`);
}
}
function DataComponent() {
const [state, dispatch] = useReducer(reducer, {
data: null,
loading: false,
error: null
});
// Actions are explicit and traceable
const fetchData = async () => {
dispatch({ type: 'FETCH_START' });
try {
const data = await api.getData();
dispatch({ type: 'FETCH_SUCCESS', payload: data });
} catch (error) {
dispatch({ type: 'FETCH_ERROR', payload: error.message });
}
};
}
// Pattern 3: Make impossible states impossible
// BAD: Multiple booleans that can conflict
const [isLoading, setIsLoading] = useState(false);
const [isError, setIsError] = useState(false);
const [isSuccess, setIsSuccess] = useState(false);
// What if isLoading AND isError are both true?
// GOOD: Single status that can only be one thing
const [status, setStatus] = useState('idle'); // 'idle' | 'loading' | 'error' | 'success'Performance Patterns
// Memoize expensive computations
const expensiveValue = useMemo(() => {
return computeExpensiveValue(a, b);
}, [a, b]);
// Memoize callbacks passed to children
const handleClick = useCallback((id) => {
setSelected(id);
}, []);
// Memoize components that receive stable props
const MemoizedChild = React.memo(function Child({ data, onClick }) {
return <div onClick={onClick}>{data.name}</div>;
});
// Don't over-optimize! Profile first
// BAD: Premature optimization everywhere
const value = useMemo(() => a + b, [a, b]); // Simple addition doesn't need memo
// GOOD: Optimize what matters
// - Large lists with React.memo on items
// - Expensive computations with useMemo
// - Context values to prevent cascading rerendersError Boundaries
class ErrorBoundary extends React.Component {
constructor(props) {
super(props);
this.state = { hasError: false, error: null };
}
static getDerivedStateFromError(error) {
return { hasError: true, error };
}
componentDidCatch(error, errorInfo) {
console.error('Error caught by boundary:', error, errorInfo);
// Log to error reporting service
}
render() {
if (this.state.hasError) {
return this.props.fallback || <h1>Something went wrong.</h1>;
}
return this.props.children;
}
}
// Usage: wrap parts of your app
<ErrorBoundary fallback={<ErrorPage />}>
<FeatureComponent />
</ErrorBoundary>Mental Model
Abramov approaches React code by asking:
- Where should this state live? As low as possible, as high as necessary
- Is this predictable? Can I trace how we got here?
- Can this be composed? Small pieces that combine well
- Is this testable? Pure functions, clear inputs/outputs
- What can go wrong? Error boundaries, loading states
Signature Abramov Moves
- Composition over inheritance, always
- Custom hooks for reusable logic
- useReducer for complex state transitions
- Make impossible states impossible
- Colocate state near usage
- Memoize strategically, not everywhere