JS-App Part 2: End of Sprint
It's been 1 week since you rendered a view...
Introduction
*checks watch*
Only three days past the deadline!
*remembers watch is broken and his replacement from Project Watches is backordered*
Whatever!
Real Introduction
The time has finally come. After months of CSS, PHP, and tinkering with JavaScript exercises from CodingJS and Exercises for Programmers, it was time to dive in and create a web application. As the pros say, it’s a 0 → 1 development cycle, which is basically agency-jargon for “start from scratch.”
Speaking of idioms, I fully understood that “the only way out is through.” You can read about it, even practice it, but identifying the pieces and connecting them - in context - is where it all joins together like sashimono.
Overview
The challenge was to make an application completely in JavaScript to serve as an MVP (minimal viable product) that you could potentially pitch to an investor or show at a code review. The point is to show that your idea works and that it has basic functionality where it counts.
I didn’t want to waste time debating on the perfect topic or to flex, since I knew I would need a lot of time to think through the design. My wife and I were talking about traveling, which inspired me to make a travel application that helps you find local guides for an authentic experience - and with the added benefit of language immersion! OF COURSE it exists already as it’s own product, as well as a sub-feature of Airbnb, but that didn’t deter me. If I were to make this full-fledged, I would focus on the education / language aspect anyway.
After researching “travel” style from these websites (primarily neutral colors, a bold accent color for pop, safe but dynamic typeface, rounded corners, gentle box-shadow), I thought about features. If I were a user, I’d want the ability to login and to store my booked trips. I’d want to browse trips by location and keywords. Ideally searching by date and availability would be great to include, but for this exercise, I didn’t want to get bogged down in date formats or use external API). I’d also want to know about the tour guide and the price per person.
Difficulties
The first problem I encountered was - where to start? Should you go through each page 100% style and features, or should you get the skeleton of the navgiation down? According to Derek, and it might make sense to start with the hardest thing - because that might create the longest blockers. Imagine reaching the end of the sprint and then beginning the toughest challenge when you are tired and just want to eat peanut m&ms and take a long shower.
Handling navigation meant saving state somewhere (aka, where you are). Every time a page rendered (gets painted on the screen), you had to save your state - or load your state! Reminded me of the fond days of emulating Super Nintendo games. It also meant creating a rudimentary router, that based on your state, a certain page would render.
After that got settled, I realized I needed to separate my functions. There are functions that handle computations, functions that handled the rendering, functions that grab or store date, and overall ‘structual’ functions that handled the other functions! I also encountered the joy of managing lots of imports and exports between files (which apparently is what happens in frameworks).
The Project
You can see it in action here.
Key Takeaways
Pseudo-code / talking to yourself (or an object) is the gift that keeps on giving! This includes making a todo list and checking them off to show progress. I never used to be a todo list guy, but perhaps that’s because I didn’t have a lot of things todo … at the time … womp.
Make sure your data is organized. The more complex the JSON, the more you’re going to have to work to extract the data you need. Things can be as complicated or as simple as you want.
Reusability and modularity is the name of the game. I could see refactoring this into a class. I could also see keeping it as distinct functions. Naming what you need, of course, is the challenge.