This chapter summarizes WHY our project is structured the way it is – a deliberate look back across both series ("React Native for Beginners" + "React Native for Professionals"), with a particular focus on the differences from "React for Professionals" chapter 45 (web).

The folder structure in hindsight

EXACTLY the same type-based structure as the web counterpart: screens/ (corresponds to pages/ on the web), components/, store/, api/, types/. ONE difference stands out immediately: no more hooks/ folder – we removed it in chapter 2, since useCart.js was fully replaced by store/cartStore.ts. A good reminder: folder structures aren't an end in themselves, they should evolve alongside the actual architecture, not linger as leftover cruft.

Naming conventions: identical, with one RN addition

All conventions from "React for Professionals" chapter 45 apply unchanged (PascalCase components, the use prefix for hooks, handle/on prefixes for event handlers/callback props). RN-specific addition: screen components CONSISTENTLY carry the Screen suffix (ProductListScreen, CartScreen), NOT Page like the web counterpart – a small, but firmly established convention in the RN community that immediately signals "this is a navigation destination", not "this is a reusable component".

When to split a screen file?

ProductListScreen has become one of our larger files after 5 chapters (badge, favorites, performance tuning). EXACTLY as recommended in "React for Professionals" chapter 45: the search/filter logic could be extracted into a custom hook, the header badge logic into its own component. One RN-specific additional candidate: a complex FlatList's getItemLayout/keyExtractor/renderItem functions can often sensibly be defined OUTSIDE the component function (as standalone, named functions instead of inline definitions), which improves both readability AND performance (stable function references, see chapter 5).

Platform-specific code: an RN-only organizational pattern

A pattern with no equivalent in the web counterpart: files with .ios.tsx/.android.tsx extensions get resolved AUTOMATICALLY per platform by Metro, without having to write Platform.select() (see "React Native Reference", the "Get Platform and Device Details" topic) explicitly in the code:

components/
  ShareButton.ios.tsx      # loaded automatically on iOS
  ShareButton.android.tsx  # loaded automatically on Android
  # Both export the same component under the same name -
  # the rest of the app just imports "./ShareButton", without knowing the platform

Use this pattern when the implementation differs so much BETWEEN platforms that Platform.select() inside ONE file would become unwieldy – for smaller differences (like our elevation/shadow* example from the "React Native Reference" series), Platform.select() stays the simpler choice.

ESLint for React Native

npx expo install --dev eslint eslint-config-expo

eslint-config-expo is the RN-specific equivalent of eslint-plugin-react-hooks from "React for Professionals" chapter 45 – it includes the same hooks rules PLUS additional, Expo/RN-specific rules (e.g. warnings for deprecated Image props that should be replaced with expo-image equivalents).