> ## Documentation Index > Fetch the complete documentation index at: https://imscodingprojects.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Journal - Person 1 > Personal reflections and development updates from Person 1. ( D ) * Installed Expo locally and created a first test project to explore the tooling. * Read the official Expo Router "Core concepts" documentation to understand file-based routing. * Created a small local playground app to experiment with basic navigation behavior. * Core problem: Understanding Expos file-based routing style without prior Next.js experience to compare it to. * It occurred because routes are derived directly from the folder and file structure, which felt very different from traditional route configuration. * I identified the issue when I was unsure how screens were picked up from the `app/` tree and clarified it by reading the docs and discussing questions with a colleague. * Carefully walking through the Expo Router core-concepts documentation and examples. * Recreating a minimal route setup in a local test project to see how file names map to screens. * Asking a colleague targeted questions to validate my oberservation of how routing and layouts work. * Expo Router heavily relies on a clear `app/` folder structure, since files and folders define the navigation tree. * I understand routing concepts faster when I combine documentation with hands-on experimentation instead of only reading. * Early questions to a teammate help avoid building on wrong assumptions. * I will always create a small playground project immediately when learning a new routing system. * Read official docs, reproduce a minimal example, then validate understanding with a colleague. * Expo Router basics - `app/` folder represents the route tree, each file is a screen and `_layout.tsx` files wrap related screens instead of a single central `App.tsx`. * No unresolved technical issues remain the basic routing concepts are clear enough to continue experimenting. * Attempt 1: Trying to understand routing purely by reading without touching code the concepts stayed too abstract. * Attempt 2: Mapping Expo Router mentally to a classic "manual route config" approach instead of accepting file-based routing as the core concept this caused extra confusion. * Deepen understanding of dynamic routes, route groups and nested layouts in Expo Router. * Watch or read material specifically focused on `_layout.tsx` and advanced navigation patterns. * Key challenge: Getting used to Expos file-based routing and layout concept without prior Next.js experience. * Attempted solutions: Read core documentation, built a small local test project and clarified open questions with a colleague. * Open questions: Details of dynamic routes, nested layouts and best practices for structuring larger apps. * Continued studying Expo Router, focusing on `_layout` files and router notations. * Tested different route patterns and layouts in the local project to see how the router behaves in practice. * Integrated the existing Spring Boot backend from the "OrariAperti" project and added Docker configuration for it. * Core problem: Understanding how `_layout` files define navigation structure and how route notations map to screens. * It occurred because Expo Router uses conventions like `_layout.tsx`, grouping folders and dynamic segments that are not obvious from filenames alone. * I overcame this by translating the documentation examples into concrete experiments inside the local project and observing the results. * Re-reading the layout documentation with a focus on how `_layout.tsx` wraps child routes. * Building a small route tree with a root layout and nested screens to see which layout wraps which screen. * Setting up Docker for the Spring Boot backend so it can be started consistently for future integration with the app. * Each directory in `app/` can own its own `_layout.tsx` and that layout becomes the wrapper for all sibling routes in that directory. * Trying router notation in a small sandbox app is much more effective than trying to memorize routing rules. * Having a Dockerized backend prepared early simplifies local development and onboarding for others, I myself didn't need it. * For future projects, define the root `_layout.tsx` early and plan how route groups map to main UX flows. * Standard approach for router notation issues: create a minimal directory structure and run the app to see how Expo Router resolves it. * No major unresolved problems I still need more experience with complex router notations, but basic layouts and routes work. * Attempt 1: Re-reading docs repeatedly without implementing examples, which did not help internalize router notation. * Attempt 2: Trying to reason about layouts only in theory without checking which screens they actually wrap in a running app. * Investigate advanced routing features: dynamic segments, modals and route groups. * Draft an internal guide defining recommended folder patterns for this project, so all team members use the same conventions. * Key challenge: Understanding `_layout` files and router notations in Expo Router. * Attempted solutions: In-depth reading of layout docs, hands-on experiments and structuring a test app to observe layout behavior. * Open questions: How to structure the final `app/` tree for scalability and clarity. * Implemented and tested navigation between screens using buttons wired to Expo Router. * Read up on React Native core and reusable components to better understand the building blocks for our UI. * Added the logo from the previous project for future use in the current apps design. * Core problem: Connecting reusable UI components (like buttons) correctly with navigation so that route changes trigger as expected. * It occurred because reusable components add an abstraction layer and navigation logic must be passed down or handled via hooks in a clean way. * I solved it by first testing simple navigation with basic buttons, then refactoring the working pattern into more reusable components. * Reviewing React Natives core components documentation to understand the standard primitives like `Card`, `Alert` and `Button`. * Creating placeholder routing buttons that navigate to different routes and verifying their behavior. * Gradually wrapping navigation logic in reusable components instead of abstracting everything from the start. * Implementing navigation with very simple placeholder buttons first makes debugging easier before adding styling and logics. * Reusing existing assets such as logos early encourages consistent visual identity. * Start with basic, direct navigation calls in simple components, then extract reusable variants once the behavior is stable. * Store reusable components in a dedicated folder and clearly document their props, including any navigation-related props. * Base UI on core React Native components, then wrap them into custom components that share styles and behavior. * No major unresolved problems navigation via placeholder buttons is working and can be extended. * Attempt: Mixing navigation and presentation logic too tightly, which reduced component reusability. * Improve reusable component APIs (props, variants, theming) and documentation. * Add more complex navigation flows such as stacks and tabs controlled via `_layout.tsx`. * Key challenge: Connecting reusable components cleanly with Expo Router navigation. * Attempted solutions: Built placeholder routing buttons, consulted React Native core component docs and then refactored into reusable components. * Implemented and tested navigation between screens using buttons wired to Expo Router. * Read up on React Native core and reusable components to better understand the building blocks for our UI. * Added the logo from the previous project for future use in the current apps design. * Core problem: Connecting reusable UI components (like buttons) correctly with navigation so that route changes trigger as expected. * It occurred because reusable components add an abstraction layer and navigation logic must be passed down or handled via hooks in a clean way. * I solved it by first testing simple navigation with basic buttons, then refactoring the working pattern into more reusable components. * Reviewing React Natives core components documentation to understand the standard primitives like `Card`, `Alert` and `Button`. * Creating placeholder routing buttons that navigate to different routes and verifying their behavior. * Gradually wrapping navigation logic in reusable components instead of abstracting everything from the start. * Implementing navigation with very simple placeholder buttons first makes debugging easier before adding styling and logics. * Reusing existing assets such as logos early encourages consistent visual identity. * Start with basic, direct navigation calls in simple components, then extract reusable variants once the behavior is stable. * Store reusable components in a dedicated folder and clearly document their props, including any navigation-related props. * Base UI on core React Native components, then wrap them into custom components that share styles and behavior. * No major unresolved problems navigation via placeholder buttons is working and can be extended. * Attempt: Mixing navigation and presentation logic too tightly, which reduced component reusability. * Improve reusable component APIs (props, variants, theming) and documentation. * Add more complex navigation flows such as stacks and tabs controlled via `_layout.tsx`. * Key challenge: Connecting reusable components cleanly with Expo Router navigation. * Attempted solutions: Built placeholder routing buttons, consulted React Native core component docs and then refactored into reusable components. * Started writing the detailed documentation for the upcoming lesson and completed steps 1-8 of the 16-step lesson preparation. * Read through the lesson preparation guidelines to ensure alignment with expectations. * Clarified several question marks directly with the teacher to make sure the content matches the required structure. * Core problem: Interpreting some questions in the lesson preparation template and understanding the expected level of detail. * It occurred because certain instructions were open-ended, leaving room for different interpretations. * I overcame this by asking the teacher for concrete examples and confirmation before finalizing my answers. * Reading the full lesson preparation document once from start to finish before filling it out. * Drafting answers for steps 1-8 and then validating unclear parts with the teacher. * Refining the wording based on feedback so that the document reflects the actual teaching goals. * Clarifying expectations early with the teacher saves time and reduces the risk of rewriting sections later. * Using the lesson document as a shared artifact helps communicate goals within the team. * I work more effectively on documentation when I can ask questions instead of guessing the intended meaning. * Best practice: For lesson plans, skim the whole template first, then fill it in sequentially and clarify ambiguous parts right away. * Standard approach: Use consistent terminology between the lesson plan and the example code to avoid confusion. * Documentation note: Keep lesson steps numbered and concise so they can later be reused as student-facing instructions. * No unresolved issues steps 1-8 are completed and aligned with the teachers expectations. * Attempt: Trying to guess certain answers without asking the teacher, which led to uncertainty and possible misalignment. * Continue with steps 9-16 while maintaining a feedback loop with the teacher. * Start drafting example code or visual material that will be used during the lesson. * Key challenge: Understanding and correctly filling in lesson preparation steps 1-8. * Attempted solutions: Thoroughly read the template for lesson preparation, drafted answers and clarified uncertainties with the teacher. * Open questions: How detailed the practical React Native examples in the later lesson steps should be. * Completed steps 9-16 of the lesson preparation, finalizing the planned documentation. * Refined ideas for the React Native tutorial that will be the core of the upcoming lesson. * Learned how to create a reasonably structured markdown table and used this in the documentation. * Core problem: Staying focused and consistent while finishing the remaining lesson preparation steps. * It occurred because the documentation workload was high and required careful wording. * I managed it by asking the teacher whenever something was unclear and by breaking the work into smaller, manageable chunks. * Working through each remaining step one by one instead of multitasking across the document. * Clarifying remaining questions with the teacher to avoid misinterpretations. * Experimenting with markdown table syntax until the table looked clean and readable. * Breaking down a long documentation task into smaller steps made it easier to maintain quality and focus. * Practical experimentation is the fastest way to learn markdown features like tables. * Thinking about the React Native tutorial early helps ensure that code examples align with the written lesson goals. * For future lesson documents, define the main example or topic (e.g, a React Native feature) early and align all steps with that example. * Use markdown tables for structuring recurring information such as topic, goal, activity and duration. * Keep markdown tables simple, with a small number of columns and consistent formatting, so they stay readable in different tools. * No unresolved problems, all 16 lesson preparation steps are completed and clarified where needed. * Attempt: Writing markdown tables from memory without checking syntax, which led to formatting errors. * Flesh out the concrete React Native tutorial steps, including the sequence of code examples and potential live-coding. * Prepare slides or handouts that reuse the markdown tables and core points from the lesson documentation. * Key challenge: Finishing the remaining lesson preparation steps and shaping the React Native tutorial concept. * Attempted solutions: Worked sequentially through steps 9-16, asked the teacher for clarification when needed and experimented with markdown tables. * Open questions: Final decision on how advanced the React Native example should be for the target audience. * Reworked and refined my existing journal entries (Days 1-3). * Transferred and published these journal entries to Mintlify. * Improved formatting and consistency to match documentation standards. * Core problem: Ensuring that previously written journal entries were properly structured and formatted for Mintlify. * It occurred because the original notes were not fully aligned with the documentation format and required adjustments. * I resolved it by systematically reviewing each entry and adapting it to the expected structure. * Reviewing earlier journal entries for clarity and completeness. * Aligning formatting (headings, spacing, structure) with Mintlify requirements. * Iteratively updating entries and previewing them to ensure correct rendering. * Retrospectively refining documentation improves both clarity and consistency. * Writing with the final documentation platform in mind (Mintlify) saves time later. * Small formatting differences can significantly affect readability in documentation tools. * Always align documentation early with the target platform (e.g, Mintlify). * Periodically revisit and refine earlier entries instead of treating them as final. * Maintain consistent formatting conventions across all journal entries. * No unresolved issues the migration of Days 1-3 to Mintlify was completed successfully. * Attempt: Copying entries directly without adjusting formatting, which resulted in inconsistent presentation. * Continue refining later journal entries for consistency before publishing. * Explore reusable templates for future journal entries to standardize structure. * Key challenge: Adapting earlier journal entries to Mintlify formatting standards. * Attempted solutions: Reviewed, restructured and incrementally refined entries before publishing. * Open questions: None at this stage. * Published the remaining journal entries to Mintlify. * Finalized the documentation so all work logs are now centrally available. * Clarified the structure of the AVIVA table for the lesson documentation with the teacher. * Core problem: Understanding how to correctly structure the AVIVA table for the lesson. * It occurred because the required structure needed to reflect the chronological flow of the lesson. * I solved it by discussing it with the teacher, which led to adapting the structure into an "AVIVVIVVIVA" format. * Asking the teacher directly how the AVIVA table should be structured. * Reviewing the lesson flow and aligning it with the adapted AVIVVIVVIVA structure. * Updating the table to ensure it reflects the chronological teaching process. * Clarifying structural questions early avoids incorrect documentation work. * Standard frameworks like AVIVA may need adaptation depending on the lesson flow. * Direct communication is often the fastest way to resolve conceptual uncertainties. * When working with teaching frameworks, adapt them to fit the actual lesson flow instead of forcing strict structure. * Always validate unclear documentation requirements with stakeholders (e.g, teacher). * Keep documentation aligned with real chronological processes for better usability. * No unresolved problems all journal entries are now published and the AVIVA structure is clarified. * Attempt: Trying to structure the AVIVA table independently without clarification, which led to uncertainty. * Refine the AVIVVIVVIVA table further based on feedback after first use in the lesson. * Create a reusable template for future lesson documentation. * Key challenge: Structuring the AVIVA table correctly for the lesson. * Attempted solutions: Asked the teacher for clarification and adapted the structure accordingly. * Open questions: Whether the adapted AVIVVIVVIVA format will need further refinement after practical use.