Day 2 of the 7-Day Challenge: Full Throttle—From Skeleton to Live Data
Day 1 was a battle—a 2.5-hour grind against a stubborn setup error. Today was the reward. The resolution of that initial struggle unlocked a state of pure, productive flow.
This post covers the work I had planned for Day 2 of my 7-day challenge. The truth is, I accomplished all of this in a hyper-focused 2-hour session yesterday, right after solving the Day 1 issues. This is the part of software development I love: when the foundation is solid and you can just build.
Let’s break down how we went from an empty screen to a functional, data-driven app.
Part 1: Building the Skeleton & The Final Hurdles
The first order of business was to build the app’s skeleton. However, because I had to manually download the project template yesterday, the package.json file wasn’t perfectly aligned with my Expo SDK version. This led to a few final hurdles.
When I ran npm install, I was immediately greeted with a dependency conflict.
This ERESOLVE error is npm’s way of saying that different packages in the project had conflicting requirements. For example, the expo-template-blank-typescript I downloaded from GitHub specified react-native: "0.80.0", but other libraries expected a different version.
The fix was to manually edit my package.json to use the exact versions compatible with my Expo SDK, and then run the installation with a special flag: npm install --legacy-peer-deps. This tells npm to be more lenient and resolve the minor conflicts.
Here is the corrected package.json file with the aligned versions:
With that solved, I created the theme file and the bottom tab navigator. But when I ran the app, I was met with one final, unexpected error.
This _ExpoFontLoader.default.getLoadedFonts is not a function error was happening because the icon library (@expo/vector-icons) couldn’t load its fonts. The fix was to explicitly re-install the expo-font package using npx expo install expo-font.
After clearing that final hurdle, the app’s skeleton was finally complete and running correctly.
Part 2: Breathing Life into the App with Live Data
With the UI shell fully functional, it was time for the most exciting part: fetching real data from the CoinGecko API.
The API Service Layer
I created a dedicated file, coingeckoAPI.ts, to handle all API communication. This separation of concerns is vital. My UI components don’t need to know how the data is fetched; they just need to receive it. I used axios for the HTTP request and defined a clear TypeScript Coin interface to ensure my data was strongly typed.
The PriceTicker Component
Before displaying a list, I needed to design the row. I built a reusable React component called PriceTicker.tsx. It takes all the necessary data for one coin and renders it in a clean layout. A key detail here was styling the price change percentage: green for positive, red for negative, using the colors from our theme file.
The Markets Screen & The FlatList
This is where everything came together. I updated the MarketsScreen.tsx file to use a useEffect hook to call my API function when the screen loads and store the data in state. The list itself is rendered using React Native’s <FlatList> component, which is essential for performance with long lists.
The Result: A Day of Pure Flow
In what felt like a blink of an eye compared to yesterday, I went from a blank screen to this:
…
The speed and progress were exhilarating. It’s a testament to the power of a stable environment and the force-multiplying effect of modern tools. In fact, I was so in the zone that after finishing this work, I immediately started on the tasks planned for Day 3 in the same evening session.
This post covers the first half of my hyper-productive Saturday. In the next post, I’ll share the results of that second session, where I tackled real-time data with WebSockets, charting, and the perils of --force.
Join the Discussion
I’m documenting my journey to learn in public. Your feedback is a crucial part of that process.
1. What part of this post was most valuable to you?
- (A) The details on resolving
package.jsonconflicts. - (B) The architectural approach (API layer, reusable components).
- (C) The story of overcoming struggle to find a flow state.
Let me know your answer (A, B, or C) in the comments below!
2. A Question For You:
What’s one tool or technique in your workflow that, once set up correctly, unlocks a huge boost in your productivity and flow state?
The best way to follow this 7-day sprint is by joining my newsletter for daily updates directly in your inbox.