DEV Community: Angel Umeh

Turns Out I Never Knew What Node.js Was

Angel Umeh — Fri, 10 Jul 2026 09:04:24 +0000

I started AltSchool Africa's Backend Engineering program already knowing how to code. I had about 3 years of frontend experience (and multiple Hackerrank certificates to show for it), and had already held professional roles the year prior, so I'd shipped things. I assumed the program would mostly hand me new syntax to bolt onto what I already knew.

That assumption didn't survive the first semester. Thirteen projects later, I don't build software the same way anymore. This is the long version of that story, mostly for myself, but also for anyone weighing whether a structured year-long program is worth it when you already have some experience.

The browser was my whole world

Before AltSchool, I built interfaces. I knew how to make things look right and behave predictably in the browser. What I didn't have was a real mental model of what was happening on the other side of the request. APIs were things I consumed, not things I designed.

That changed early. Once I understood how a request actually moves through a server, gets validated, hits a database, and comes back, my frontend work started improving on its own. I started asking better questions, like why an endpoint was shaped the way it was, instead of quietly adjusting messy frontend logic around it. Frontend development became a way to visualize the systems I was learning to build, which made me sharper on the data side too. It was a side effect of finally understanding both ends of the same conversation.

Unlearning JavaScript

Somewhere in the first few months, I had a moment that felt almost embarrassing given how long I'd already been writing JavaScript. I realized I had never actually understood that Node.js is just a runtime for executing JavaScript outside the browser. Not a framework or a language extension. This reorganized a lot of loose knowledge I'd been carrying around for years.

The same thing happened with TypeScript. I'd always thought of it as just "harder JavaScript" because of the extra syntax, which is technically true but misses the point. Working with NestJS revealed the true power of TypeScript. It is the essential backbone of modular architecture, and its static typing catches entire categories of bugs before they ever exist. The fun part of this was making a codebase legible to whoever opens it next, including future me. I even realized some of the descriptive tooltips in a code editor come from intentional typing and scoping made possible with TypeScript, not some editor magic. I even picked up a HackerRank certification in Angular (Intermediate) even though it wasn't part of the program's stack, simply because I understood well enough to prove so under a clock, with no IDE hints and no Stack Overflow tab open.

I also learned the difference between an API and a server that just supplies data. That distinction sounds small until you're the one designing the boundary between what a client should be allowed to ask for and what the server hands back regardless of the request.

Learning to design data instead of just querying it

A recurring lesson across almost every project: filtering and shaping data is a database concern, not an application concern. Early on it's tempting to pull everything with a broad select('*') and slice it down in application code. It works, but it's also wasteful and it doesn't scale. Now, I ask of any new endpoint what the query itself should already be doing before the data ever reaches application code.

This connected to and refreshed the SQL experience I thought I already knew from my data science work in Python. I saw that I knew how to write queries against data someone else had already organized for me. PostgreSQL, used properly inside a real application with real constraints, forced me to think about schema design, indexing, and query efficiency in a way ad hoc data science scripts never had.

My stateless tokens were rather stately

Early in the program, I made a mistake common enough to be almost a rite of passage: I misunderstood how JWT authentication is supposed to work and often stored tokens in server side sessions (who doesn't love baking cookies, eh?), which defeats the entire point of a stateless token. JWTs are meant to be self contained and verified straight from the Authorization header on every request, no session middleware holding state on the server.

I learned why stateless authentication exists as a pattern, and every project since, including my capstone, uses proper Bearer token verification with role based access control, and I understand exactly why it's built that way instead of just copying a template.

Reopening Florence with new eyes

I'd actually already tried backend engineering before AltSchool. My first experience was when I was trying to figure out CORS limitations, and with some help from my friends I once wrote up a simple server. I even built my own startup's product, Florence*, surrounded by a lot of documentation and some AI (well before today's LLMs got as good as they have at coding).

Around the seventh month of the program when I went back to Florence, it was actually a proud moment for me to be able to laugh at my code. I could point to the exact architectural gaps, the places I'd skipped proper validation, the parts where I'd solved problems with brute force instead of a structural fix. This was one of the more validating moments of the whole course. I hadn't just learned new things in a bootcamp, I could revisit problems I'd already run into in the wild, on my own, before I had the language for them.

Projects for breakfast, lunch and dinner

AltSchool's diploma program runs three semesters. Across all three, I worked on some thirteen projects as a requisite part of my coursework, not counting theoretical assessments. My GitHub list has the full lineup:

Self intro in plain HTML
HTML tables & media
A recipe page (my renowned fried rice, naturally)
Self intro, rebuilt with CSS Flex & Grid
A stopwatch (first semester exam)
Servers & APIs
Database design
A to-do app
A blog API (second semester exam, evolved into Blogr)
A guessing game
A birthday reminder app
A restaurant chatbot
Eventful (the capstone)

It was roughly one significant submission every three to four weeks, for a full year. It was the kind of intensity I wanted, and throughout it I held myself to a standard of treating every assignment as something that should be portfolio-ready.

First semester was web fundamentals: semantic HTML, CSS Flex & Grid, responsive layouts, and JS in the browser.

Second semester was where the backend actually began: Express servers, MongoDB, REST API design, CORS, JWT and session-based auth, validating data with Joi, testing with Jest, documenting everything in Postman.

Third semester raised the ceiling: TypeScript, cron jobs, queues with BullJS, webhooks, rate limiting, logging, security hardening for Express apps, WebSockets with Socket.io, object-oriented design, server-sent events. Best part? None of it stayed theoretical. Cron jobs became the core of the reminder emails on the birthday reminder app. Webhooks became the Paystack confirmation flow in the restaurant chatbot.

By the time I got to my capstone project, I wasn't doing anything new under the pressure of a deadline or the need to make something fancy; I was simply applying patterns I'd already stress-tested a dozen times.

Part of that standard also meant documenting my APIs properly, and I did not expect to enjoy this. Documenting an endpoint forces you to step through exactly what happens: what the request looks like, what validations run, what the response looks like when everything goes right and how I find the weak points in my own code. In my attempts to make the documentation clearer and more robust, I frequently caught errors and edge cases I had forgotten to think about, which usually meant the API got better in the process of fixing them. Documentation stopped being a chore to satisfy a grading rubric and started being another phase of the real work.

One pattern that became obvious partway through the program was that Frontend Mentor challenges I'd built years ago as pure UI exercises could become full-stack, real products the moment I paired them with a proper backend. I just caught a fun opportunity to build functionality behind a design I already liked, and I didn't miss it. My favorite example is Blogr, originally a blog API built and documented for my second semester exam, that's evolved into a full stack app with design inspiration drawn from a Frontend Mentor blog landing page. The aesthetic & style was extended to more pages to better capture the API's capabilities (see it on GitHub). I wrote about that semester here.

Eventful, literally

Eventful is an event ticketing platform I submitted for my Capstone Project, and it's the clearest evidence of everything above landing in one place:

NestJS on the backend, Next.js on the frontend
Supabase/PostgreSQL for the data layer
Paystack for payments, confirmed via webhooks
Nodemailer for transactional email
QR codes generated and embedded into ticket emails, scanned at the door to mark tickets used
Scheduled reminder emails via @nestjs/schedule
JWT auth with role separation: creators get event management and analytics, eventees get ticket purchasing and their own history
API Docs on Postman

None of these pieces were unfamiliar by the time I built them. I'd already used Paystack for Florence* and on prior assignments like the restaurant chatbot. I'd worked with Supabase and PostgreSQL enough times that schema design felt automatic instead of intimidating, I even knew how to drop and recreate tables. The QR flow, encoding a ticket identifier, generating a PNG, storing it, verifying it later, was new in the specific implementation but not conceptually foreign, specifically because I'd already built comparable verification flows for smaller assignments, but generally because my time in AltSchool had reinforced in me how to use the knowledge I already have to gain more.

I was selected to present Eventful at my pre-graduation showcase, and by all accounts it went well. Part of that came down to something I already had before the program: an eye for clean, consistent visual design, which you might notice in the slides. But most of it came down to preparation: because the capstone wasn't far removed from a year of assignments and prior years of experience in technical communication & presentations, I could easily tell a technical story to a mixed audience without hesitation.

The multitasker

AltSchool ran concurrently with my NYSC service year. I remember missing my opening parade march to write my AltSchool entrance exam, which I scored 90% on. By the time NYSC wrapped up on 21st May this year, I was eagerly awaiting the start of my capstone exam, which I submitted a fortnight later. For most of the stretch in between, I also held down full-time work: about seven months as a frontend engineer, followed by a full stack contract role for about 6 weeks. Backend fundamentals from AltSchool showed up almost immediately in decisions I was making at work, and constraints I ran into at work sharpened how I approached AltSchool assignments. It wasn't always easy to manage the schedule, but the pressure was exciting because I never had the luxury of learning something and forgetting it before I got to use it.

In the same May, I built and shipped my portfolio site after almost 8 months of putting it off. It is live at angelumeh.dev, with most of what's here in more detail than a single article can hold.

More than code

AltSchool's coursework wasn't only practical. Alongside the assignments there were quizzes that tested understanding, which separated it from being yet another code-and-submit bootcamp. But the part I didn't expect was the career support layered on top of the technical curriculum. CV positioning, application strategy, and professional presentation and communication were treated almost as seriously as the code. Some of it I already knew from experience, but it was a pleasant relief to know that AltSchool reinforced these things (and would have taught me regardless). I've since learned to present myself better as a candidate, a skill I've been approximating on my own for a long time.

I'm really grateful for the friends who supported and encouraged me through the program, especially Zubair (@zubs) who always had the time to read my code and helped me see the process of API documentation for what it is; and Edwin who helped sharpen my understanding of database design. Working near experienced people and getting called out kindly but clearly made it more real and a lot less academic.

What's next

A year of AltSchool didn't just add backend skills to a frontend résumé. It gave me a way of thinking that connects both sides of a system, and thirteen projects' worth of proof that it wasn't accidental.

What's actually next though is I'm searching for my next role. I build across the stack and I'm open to a role that connects me to talented people and allows me to build the way this past year has taught me to. If you're deciding whether a program like this is worth it when you already have some development experience, my answer is this article. 😁

Author

Thank you for reading this far! Connect with me via:

Responsive Space Tourism App with React Native: What I Built & What I Learned

Angel Umeh — Fri, 22 Aug 2025 15:29:50 +0000

Overview
About the Project
- Goals
- Tools & Stack
- Features
- Links & Demo
What I learned
- More React Native Components
- State Management with useRef
- Data Persistence with AsyncStorage
- Improved Animations & Gestures
- Challenges
Final Thoughts

Overview

For my second swim in React Native development, I tackled a Frontend Mentor challenge to build a space tourism app.

This was my second project built with React Native & Expo, and is the second project in my 60-day React Native challenge.

About the Project

Goals

Build my second React Native cross-platform app
Build on and advance in styling in React Native & writing CSS-in-JS
Implement improved interactivity in my app
Learn about & implement data persistence with AsyncStorage

Tools & Stack

React Native + Expo
React Native Animated API
TypeScript
AsyncStorage
Route management with Expo Router

I primarily used Expo Router for navigation, though React Navigation could also have been a fit. I chose Expo Router for its file-based simplicity.

Features

This is an interactive space tourism introduction. Users can:

View each page
Toggle between the tabs to see new information
View the optimal layout for each of the website's pages depending on their device's screen size
See hover states for all interactive elements on the page. On native devices, “hover states” translate to touch feedback rather than mouse hover.
[Extra] Come back to their last viewed sections on each page

Links & Demo

You can find the app here:

This live link is the web export of the React Native app via Expo, deployed on Netlify.

Some snippets:

Mobile Screenshots:

Desktop Screenshots:

What I learned

More React Native Components

I discovered more React Native components in this project, a little further removed from web development this time.

<ImageBackground source={getBg()} style={styles.bg} resizeMode="cover">
    <ScrollView contentContainerStyle={styles.content}>
        // Your content here
    </ScrollView>
</ImageBackground>

I learned to use ImageBackground for full-screen background images that adapt to different screen sizes, and ScrollView with contentContainerStyle attribute for better content layout control within scrollable areas.

State Management with React `useRef`

useState remained an important part of my toolbox, managing the animation states, but useRef allowed me to maintain animation values that would update frequently but that don't trigger re-renders.

const slideAnim = useRef(new Animated.Value(50)).current;
const scaleAnim = useRef(new Animated.Value(0.95)).current;

Data Persistence with AsyncStorage

Just like JS localStorage, AsyncStorage allowed me to store and persist user choices like the selected destination or the last viewed crew member.

// Save user selection
await AsyncStorage.setItem('lastDestination', destination.name);

// Load on app startup
const lastDestination = await AsyncStorage.getItem('lastDestination');

Improved Animations & Gestures

I got a much clearer understanding of the anatomy of a typical gesture, thanks to @eveningkid's YouTube tutorials. I was able to progress from single animations to coordinated animation systems. On re-reading the React Native Animated docs, I found methods like sequence(), parallel(), stagger(), and loop(). I mostly used parallel():

Animated.parallel([
    Animated.timing(slideAnim, { toValue: 0, duration: 400 }),
    Animated.timing(scaleAnim, { toValue: 1, duration: 400 })
]).start();

Distinct Responsive Layouts based on screen size

Rather than just scaling elements, I learned to create fundamentally different layouts, where mobile stacks all the page content vertically, while desktop uses a two-column layout, each optimized for their respective interaction patterns.

Challenges Faced

Platform differences: \ I realized that many functions, effects or other behaviors that seem normal on web may not apply on real devices.

menu: {
    backgroundColor: 'rgba(11, 13, 23, 0.15)',
    backdropFilter: 'blur(40px)', // Works in browser, not iOS
}

Gestures: \ Making a functional multi-part gesture required me to properly understand the anatomy of a gesture. @eveningkid's tutorials helped me get that gestures are comprised of a start, a behavior, and a release.

Final Thoughts

I enjoyed building this app. It was quite the challenge, but it helped me flex my layouts muscle.

I also learned to create animation systems for smooth effects, and implement slightly more complicated gestures. Thanks to this project, I learned the anatomy of a gesture, and this will serve as a building block for more complicated ones in the future.

This project is part of my summer side quest.
You can follow me on X & GitHub to keep up with the full challenge.

To-do App with React Native: What I Built & What I Learned

Angel Umeh — Sun, 10 Aug 2025 22:33:46 +0000

What Happens When A Web Developer Discovers Mobile Development?

Let’s see!

Overview

For my first dive into React Native development, I tackled a Frontend Mentor challenge to build a fully-featured to-do app.

This project was my first foray into the world of React Native & Expo, and is the first project in my React Native learning journey.

About the Project

Goals

Build my first React Native cross-platform mobile app
Learn styling in React Native & writing CSS-in-JS
Master fundamentals of mobile UI patterns
Implement animations and interactive gestures

Tools & Stack

React Native + Expo
React Native Animated API
React Native Reanimated library
TypeScript

Features

This is a simple to-do app with all the basic functionality, as well as a few advanced interactions. Users can:

Add tasks
Mark tasks as complete
Delete tasks
Filter tasks: view all, active or completed tasks
Clear all completed tasks in one click
Switch app between light & dark themes
Drag & drop to reorder items

Links & Demo

You can find the app here:

Some snippets:

What I learned

React Native Components

Components are the essential building blocks of React Native apps.
They are analogous to other common elements used in web, Android and iOS app development.

In this project I dealt directly with the following:

View
Text
Button
Image
TextInput
TouchableOpacity
ScrollView
FlatList

Coming from a web development background, it was very interesting to draw the following parallels:

React Native Component	Web Equivalent	Description
`<View>`	non-scrollable `<div>`	A simple box that accepts layout, styling, user controls and accessibility controls, representing its children (however, does not scroll)
`<Text>`	`<p>`, `<span>`	Used for displaying strings of text
`<Button>`	`<button>`	A basic button with native styling (hence it looks different on web vs iOS)
`<Image>`	`<img>`	An element that displays most types of pictures / images
`<TextInput>`	`<input type="text">`	An input item that takes text
`<TouchableOpacity>`	`<button>`	A more customizable button with native touch feedback & accessibility that can nest other content like images
`<ScrollView>`	`<div>`	A simple scrollable box that accepts layout, styling, user controls and accessibility controls, representing its children and rendering all its items at once
`<FlatList>`	`<li>`	A list, with lazy rendering for large datasets.

Styling in React Native - `Stylesheet.create()`

React Native styling felt familiar. Here, CSS must be written in a JavaScript Object that is then passed into the Stylesheet.create() function. Then when any new element is created, the specific style(s) that apply are called in its style attribute. For example:

const styles = Stylesheet.create({
    container1: {
        backgroundColor: #d34a76,
        width: 100,
    },
    container2: {
        backgroundColor: #c23ad4,
        width: 200,
        fontSize: 20,
        color: #38005d,
    }
});

const TestApp = () => {
    return (
        <View style={styles.container1}>
            Hi, I am Container 1.
        </View>
        <View style={styles.container2}>
            Hi, I am Container 2.
        </View>
    );
}

export default TestApp;

Some key differences from web CSS:

Flexbox by default: Every View uses flexbox layout
Column-first: Default flexDirection is column, this makes sense for mobile apps.
No cascading: Styles are scoped to components

State Management with React `useState`

State Management is used to handle data within a component that is expected to change over time - it is like storage, but for React components.

Managing many parts of my todo list required careful consideration and handling of data flow. useState was used to manage the app theme and filter the todo list, while useMemo minimized unnecessary rerenders when filtering large lists.

Using custom fonts

In an Expo project, there are two ways to import and use custom fonts other than the native font or Expo-provided fonts:

Add the font assets to your project and import them, or
Use the expo-google-fonts library - for example, my app uses Josefin Sans, so I installed expo-google-fonts/josefin-sans.
Using linear gradients in Expo
Creating animations in React Native

Animations & Gestures

I implemented two animation systems:

React Native Animated API for simple animations:

const fadeAnim = useRef(new Animated.Value(0)).current;

Animated.timing(fadeAnim, {
  toValue: 1,
  duration: 300,
  useNativeDriver: true,
}).start();

React Native Reanimated library for hold-drag-and-drop gestures

Challenges Faced

Integrating SVG Assets:
All of my icon assets were in SVG format, but React Native doesn't support SVGs out of the box. I had to:

Install react-native-svg and react-native-svg-transformer
Configure Metro bundler to handle SVG files:

config.transformer.babelTransformerPath = require.resolve('react-native-svg-transformer');
config.resolver.assetExts = config.resolver.assetExts.filter(ext => ext !== 'svg');
config.resolver.sourceExts.push('svg');

Import SVGs as React components:

import CrossIcon from '../assets/images/icon-cross.svg';

iOS compatibility issues:
I learned to always specify flex or height properties for consistent cross-platform rendering.
Animations:
Making an intuitive drag & drop gesture required that I do:
- Gesture detection: I had to use a long-press to activate it to avoid interfering with the scrolling behavior.
- Position calculations: I had to detect where exactly the dragged item was being placed and do a little math to make sure that it was dropped at the right position.
- Spring motion: I included a small spring motion in order to make it more intuitive - something being picked up should appear to lift up and away from the list (closer to the user).

Final Thoughts

It was fun to experience building mobile apps for the first time.

React Native is very similar to React. The component-based architecture, hooks, and state management patterns all translate directly from my web development experience to mobile development.

Flexbox-by-default and the component system make building responsive mobile UIs more straightforward than I expected.

The animation APIs also opened my eyes to new possibilities for creating engaging, visually appealing and intuitive UXs that improve the "mobile app" feel. There's definitely more to learn before I move on to more complex gestures.

I look forward to more complex projects and making future apps more accessible.

This project is part of my summer side quest. You can follow me on X & GitHub to keep up with the full challenge.

[Boost]

Angel Umeh — Tue, 05 Aug 2025 15:51:48 +0000

Daniel Benjamin

Aug 2 '25

How to Test Your Node.js & Postgres App Using Drizzle & PGlite

#pglite #drizzle #node #vitest

2 min read

#30DaysofCode September: My journey to DSA Mastery

Angel Umeh — Mon, 30 Sep 2024 20:05:20 +0000

This September, I embarked on a self-imposed 30 Days of Code challenge, a commitment to solve at least two Data Structures and Algorithms (DSA) problems every single day. My goal was to push myself out of my comfort zone, build consistency, and improve my problem-solving skills and programming logic.

I didn’t just stick to one platform — I completed HackerRank’s 30 Days of Code challenge, LeetCode’s 30 Days of JavaScript plan, and also tackled LeetCode’s Top Interview 150 track, a collection of 150 typical interview problems for anyone prepping for a coding interview. Additionally, I took a few lessons on Structy to further strengthen my grasp of DSA concepts.

I solved most problems using JavaScript (except for a few HackerRank problems where JavaScript wasn’t supported, so I used Python instead). To help keep myself accountable, as well as share my progress, I posted the challenges I solved each day on Twitter. You can find them in this quote trail: // Detect dark theme var iframe = document.getElementById('tweet-1840720685099864068-181'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1840720685099864068&theme=dark" }

Data Types, Basic to Advanced

Each day exposed me to different types of data structures and algorithms. I learned to handle

arrays
strings
objects
maps
sets
numbers
booleans, and more.

Some problems involved more complex structures like linked lists and binary trees, while others threw matrices / n-D arrays into the mix, letting me deal in multidimensional spaces.

The diversity of the problems kept me on my toes. The problems on LeetCode’s 30 Days of JavaScript track introduced me to fundamentals like

array transformations
function transformations
closures
classes
JSONs
Promises & time.

LeetCode’s Top Interview 150 track took things a step further, tossing me between problems of varying difficulty and approach. Solving at least one of these each day was invaluable. These problems also challenged me to think more often about optimization and how different approaches could drastically affect runtime and memory efficiency.

I also took Structy lessons alongside these challenges to solidify my understanding of key concepts. I learned more efficient ways to handle some data structures, like the sections on linked lists and binary trees. I came to especially appreciate the platform’s dynamic approach to teaching and breaking down problems in a way that makes them easy to digest. It’s a great platform to learn DSA at a very basic level and then translate this understanding to other coding problems I face.

Approaches and Techniques

As the days progressed, I encountered many kinds of solution approaches, problem-solving techniques such as

recursion
two-pointer
hashmap
hashtable
greedy algorithms
binary search
sliding window
dynamic programming
caching (memoization), and more.

I found the two-pointer approach a straightforward yet powerful way to work through problems involving sequences (primarily arrays and strings), by reducing the search space for more efficient solutions. I also used greedy algorithms where I needed to make locally optimal choices at each step.

Sliding window techniques were another eye-opener— initially challenging, but valuable for problems involving subarrays or substrings; problems that required keeping track of a moving range of elements within a sequence. Hashmaps and hashtables are great for key-value pairs in problems involving frequent lookups.

One of the most complex techniques I worked with was dynamic programming. Early on, I found DP quite intimidating due to the difficulty in recognizing overlapping subproblems, but with repeated exposure memoization became my best friend in optimizing recursive calls.

Function Manipulation (feat. Wrappers & Prototypes)

In addition to core DSA problems, I also got the chance to try out more advanced JavaScript concepts. I wrote wrapper functions, learning how to control the flow of my code and extend functionality for specific requirements. I even learned to set timers on functions which allows me handle time-sensitive operations or limit how often certain functions can execute.

Working with prototypes showed me that data types can be manipulated beyond their inbuilt capabilities by creating custom methods. This allowed me to extend the inbuilt functionality of data types like objects and arrays in new ways. I came to appreciate the importance of writing clean, modular code.

I also learned memoization, a technique where you modify a function such that it stores previously called arguments with their results! This is a kind of caching that helps improve performance in problems where there are multiple calls to the same function. I wrote about my Memoize solution that beat 99% (memory) here: Memoize Intutitive Solution beats 99% Memory.

Testing & Optimization

Another thing I started to pay more attention to during this journey was the optimization of my code. After a proper introduction to big-O notation on Structy, I understood the importance of time and space complexity and I learned the optimal technique for most common problems. Toward the end of the HackerRank challenge track, I also learned to test code using classes and to write generics.

Takeaway

By the time I completed the 30 Days of Code challenge, I felt a profound sense of growth. It improved my ability to handle a wide range of problems and deepened my understanding of JavaScript and DSA. More than just solving problems, this month-long journey was a reminder to myself that I really could put in the effort. Seeing the rewards of consistency and discipline, I have been renewed with the mindset to approach any challenge with confidence and a strong toolkit of techniques.

This experience marks a significant milestone in my programming journey. The skills I’ve sharpened over these 30 days will undoubtedly carry forward into my career as a software engineer.

I am proud of me for having put in the effort, and grateful to my friends who cheered me on and offered their support and wisdom throughout the challenge.

DEV Community: Angel Umeh

Turns Out I Never Knew What Node.js Was

The browser was my whole world

Unlearning JavaScript

Learning to design data instead of just querying it

My stateless tokens were rather stately

Reopening Florence with new eyes

Projects for breakfast, lunch and dinner

Eventful, literally

The multitasker

More than code

What's next

Author

Responsive Space Tourism App with React Native: What I Built & What I Learned

Table of Contents

Overview

About the Project

Goals

Tools & Stack

Features

Links & Demo

What I learned

More React Native Components

State Management with React useRef

Data Persistence with AsyncStorage

Improved Animations & Gestures

Distinct Responsive Layouts based on screen size

Challenges Faced

Final Thoughts

To-do App with React Native: What I Built & What I Learned

Overview

About the Project

Goals

Tools & Stack

Features

Links & Demo

What I learned

React Native Components

Styling in React Native - Stylesheet.create()

State Management with React useState

Using custom fonts

Animations & Gestures

Challenges Faced

Final Thoughts

[Boost]

How to Test Your Node.js & Postgres App Using Drizzle & PGlite

#30DaysofCode September: My journey to DSA Mastery

Data Types, Basic to Advanced

Approaches and Techniques

Function Manipulation (feat. Wrappers & Prototypes)

Testing & Optimization

Takeaway

State Management with React `useRef`

Styling in React Native - `Stylesheet.create()`

State Management with React `useState`