What importing from a barrel really loads (a model)
A model, not a real bundler: it shows that the module loader must run every file a barrel re-exports before it can hand you one name. In the dev server and in tests that cost is paid on every page load and every test file.
Group files by feature (everything about the cart in features/cart/) instead of by file type, keep each thing next to the code that uses it, put truly generic UI in a shared folder, give each feature one public entry point, and let a lint rule enforce who may import what.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Here is a type-based structure: components/{TodoList,TodoItem,LoginForm,Avatar}.jsx, hooks/{useTodos,useAuth}.js, utils/{formatDate,validateEmail}.js. Reorganise it into features and shared code.
Write the no-restricted-imports rule that stops any file from importing @/features/<name>/<anything>, and say what @/features/todos should export.
Explain it without notes
Compare a type-based folder structure with a feature-based one. When does each make sense?
What is a barrel file, and what are its trade-offs?
What is an import boundary and how would you enforce one in a React codebase?
Where should a component go if two features need it?
Preview
Console
Nothing logged yet.Expected console output
Importing Button from the barrel ran: Button.jsx (2 KB), DatePicker.jsx (48 KB), Chart.jsx (160 KB), RichEditor.jsx (220 KB)
Importing the file directly ran: Button.jsx (2 KB)