prompt.yes?(“Read on?)

Emmanuel Rivera
4 min readDec 11, 2020
Final Fantasy XIV Poster
FFXIV Poster

I started my journey at Flatiron School 2 months ago and currently finished my first major project: the CLI App. For my project, I decided to focus on the FFXIV API, more specifically, the Free Company API. What I wanted to do was to make a search function to search for any Free Company inside of the Final Fantasy XIV game. Now if you don’t know what either of these are; Final Fantasy XIV(FFXIV) is a massively multiplayer online role playing game, AKA, and MMORPG. Essentially what this means is it has the elements of a role-playing game, with an online community. A Free Company is a “group” made by a player, for players. Essentially a mini community inside the game.

I personally loved this game and was excited to know I was able to incorporate something that I loved into something I am trying to become. One feature that really blew my mind as I was working on this project were the TTY components. They were so practical and really cut down on the code. For example, one of the TTY components I used early on was tty-table. This allowed me to have my results from the Free Company API calls to be in nicely visible tables.

@free_companies.each.with_index(1) do |fc, i|fc_table = ["#".light_white, "Free Company".light_white, "ID".light_white, "Server".light_white])fc_table << ["#{i}", "#{}", "#{}", "#{fc.server}"]puts " "puts fc_table.render(:unicode)puts " "end

My code above inputs out something like this on my terminal when called:

│#│Free Company │ID │Server│

This allowed me to have good spacing and great visual as to the data I was intending to show.

While this was great, the tty component that really blew me out of the water was tty-prompt. Now I only used ONE of the many, many features it has and it still seemed to be an amazing implementation. Now as simple as it seems, it really packs a punch in ease of use as well as looking good visually in your code and in your outputs.

To give you an example of a statement written before:

def search_again_or_exit     

puts "Would you like to do another search?"
puts "Type (Y)es to search again; type (N)o to exit application:"
input = gets.strip.downcase puts " " if input != "yes" && input != "y" && input != "no" && input != "n" puts "Sorry, that is not a valid option. Please try again"
puts " "
search_again_or_exit elsif input == "yes" || input == "y" provide_fc_nameelse goodbyeend


In the code above, I have a fairly simple if/else statement. I ask a user for a prompt, in this example I ask if they’d like to do another search. I grab their input, strip, and downcase. I liked the idea of down-casing so I wouldn’t have to worry about asking the user to type exactly as the word requested AND so I wouldn’t have to code in so many different conditionals for the variations of yes. You could have yes, y, Yes… etc. That could get messy really fast. From there the code checks if it’s the correct input of either a yes or no. If it’s not, I give an error message and call the method again to try again. If it’s a yes, I send them over to my provide_fc_name method. Anything else, it exits the program.

Now while this method works but it could be better. It could be refactored and neater. Enter: tty-prompt. Boy did this component come in clutch when it came to making my code neater. Looking at the code above, it’s fine, right? It’s not THAT messy and again, it does what I need it to do. It gets the job done. However, take a look at the new and improved prompt.yes?:

def search_again_or_exitprompt = TTY::Prompt.newif prompt.yes?("Would you like to do another search?".cyan)provide_fc_nameelsegoodbyeendend

This code just went from 15 lines of code to 8. That’s almost half of the code shaven off! And the functionality of the code remains the same while ALSO adding a cleaner interface when asking the user for a yes or no prompt. As you can see that by using the prompt.yes? within an if statement, we can add a string output for the user to see. It looks exactly like this:

Would you like to do another search? (Y/n)

This is a nice, simple, and clean way to ask the user to type yes or no. You can type yes, no, n, or y and it all works. You can even type in lower-case or all-caps. It’s fail-proof too! If you type anything that is not yes or no, it gives you an invalid input error.

There is no way I will continue on my Software Engineering journey without implementing this whenever possible and I highly recommend that you do as well. If you ever want to implement this in any of your future projects, go here: