Flavor: React

As a reminder, here's a link to how this series will unfold and a guide to setting up your dev environment (coming soon).

To get started, we go into our terminal program and run a command that will haunt your dreams after a while:

This command will go through all of the installation of packages necessary to get a project up and running, and create the project folder under the name that you gave it. At the end of the install, it gives you some options for commands to run - go ahead and npm start in the console. It'll clear, and you should see that your React app is running happily on localhost:3000. If we go there using our web browser: DISCO! We're in business.

It's not much, but hey, it's yours! You made it happen. If this is your first time doing any coding: Congratulations, you've already done the thing! You can stop RIGHT HERE and I guarantee you that you can look someone in the eye at a party and tell them you've started doing web development.

Beyond the Boilerplate

Now go to your IDE of choice and open the folder you created. You'll see a file structure that looks something like this:

Even for something as simple as the page we just looked at, there's a lot of stuff that happens under the hood, and at some point or another, you might touch all of these files or, at the very least, understand what they are and why they're important. For now, we'll start by opening src/App.js, which has the code that makes up the page we saw on port 3000.

As a reminder, all code in this series is given in screenshot form. No copy-pasting!

If this looks intimidating, take a few square breaths, then let's look at the three essential parts:

1. There are the import statements that load in the spinning logo image and the other styling for the page.
2. A function App whose only job is to return the JSX (JavaScript eXtension), which is just a blend of Javascript and HTML that is compiled by the React library to make the final HTML we see in the browser.
3. The export statement for the App function. By exporting App, we make it available to the rest of our code. In this case, if you open src/index.js, you'll see the JSX tag corresponding to the exported App here.

Even in this straightforward file, you can see the whole loop that makes up React: we import things we need, declare a function to make a piece of HTML that we want, and then export it to be used somewhere else. Everything we do after this adds detail and decoration to this process.

Speaking of which, let's start by scooping out the template JSX in function App ( ) for our dice roller. We need:

1. A title so people know the name of our app. (BRANDING!)
2. An input for the number of dice to roll.
3. An input for the type of dice to roll.
4. A button to make everything GO.
5. An output area with the results from the input.

For now, we won't worry about anything WORKING, although some of it will 'work' automatically. Without doing anything fancy, we get this:

Once you're done, you can go back to the browser and behold the majesty of what you've made.

Breaking Shit

Congratulations. You've officially Broken the Shit out of something you're working on, which is a time-honored tradition in development. The whole process is to start with something simple, break the shit out of it to get it closer to what you want it to be, fix all the broken bits, and wind up with something new that you'll get to break all over again.

You'll also notice in your console that React isn't happy with us either:

This is an easy fix - remove the import logo statement from the beginning of the file and save it again. Voila! Typically, this is how it works: I fix things in the console first, since those will eventually stop everything from building, leaving you looking at Javascript errors. Then, I fix all the visual problems and get things back to looking pretty. (Note: In this case, we're just going to concentrate on getting things LEGIBLE, with minimal fuss.) To do that, we go into the App.css and replace the contents with the CSS below.

Which when we look at the app again in the browser, gives us a much better result.

You should see the app in the middle of the screen, and it may have white columns on either side where the max-width ends, but your screen continues. Feel free to play around with any of the styles in this file. This isn't a styling tutorial, which is worthy of a whole tutorial in and of itself. Feel free to experiment and take everything in a completely different direction as we go along - I'll be cleaning up and making things fancy between iterations. The next starting point may look different than where we finish. Just remember that functionality is essential; don't get so lost in the weeds that you can't follow along. There's always time to go wild after everything works.

Adding Reactivity

This 'works' in that you can adjust the number of dice up or down, choose different sides of the dice, and endlessly click on the button. None of it is hooked up to anything else, so let's do that. Let's go back to App.js and add some actual React logic to the App function before we return the JSX:

In React, you use a number of "hooks" to connect the UI (and the user) to data. useState boils down to:

1. Identifying a value we need to keep track of (the number of dice to roll)
2. Saving that value somewhere we can use it and find it later for display (diceCount)
3. Exposing a function so we can change that value through our input (setDiceCount)

Which is what Line 5 boils down to. We then repeat that for the other values we care about in our app:

1. The number of dice we roll.
2. The sides (maximum value) of each of those dice.
3. The set of results we get from rolling them.
4. The total of our set of results.

So, we set up all of those variables and their associated functions, then apply them where needed in the UI. For example, the number of dice input needs to display the number of dice and the function to change it get applied to the number of dice input and the number of sides input:

In the input section, we're assigning the number of dice input to the diceCount variable. You can prove this works by changing the number of dice to roll in the code. On Line 5 of App.js, set useState(2) to useState(10) or any other number, and check the UI again. You should see whatever value you've put in there. The same applies on Line 6 of App.js with the number of sides.

Changing those values through the UI requires that we listen for when the input's value changes, then pass the new value to our diceCount variable. To do that we use the onChange hook. When that hook is called, it doesn't just get the new value – it gets the entire event associated with the user making a change. We take that event, pick out the part we need (e.target.value) and pass that into the setDiceCount( ) function. Then we do the same thing with the diceSides selector.

Next, we'll hook up the ROLL button to take our input and generate the results. First, we need to make the function that does the work, putting it under the section where we declare all our variables. Hang onto your boots:

Once we have the function written, we simply attach it to the button using the hook for the event we want to associate with it: onClick

Finally, we add our output to the output section. The total is self-explanatory. For the results, remember that we have an Array of values. Arrays have a built-in function, map, that goes through the array item by item, performing the same function for each slot. In our case, we want to take the result in that slot and make a new list-item in our list for it:

We also put the total where it belongs in the template as well.

After we're done, we check the console for any issues, fixing anything that it complains about, or giving ourselves a quick high-five if the console is clear.

And so we can test it out in the browser:

Wrapping Up

So now we've:

• Started our project in React.
• Made the basic input and output functionality.
• Styled our app so that it is not a complete eyesore.
• We tested our work to make sure it worked as expected.

Next, we will do it all over again ... in Vue!

For our first project, we will make a dice-rolling app. We'll take it from a simple (and ugly) one-trick pony web page to a for-real progressive web application that we will package up for the Apple App Store and Google Play for 99¢.

A Dice-Rolling App? Really?

I have several reasons for choosing a dice-rolling app as the first project I'll walk through here. The first one is that I am really, really tired of to-do apps. Yes, they have all of the input, output, and UI elements needed for any web application, but MY GOD, they're so boring.

The second is that once you grasp the basics, you can go in many different directions depending on your interests. Want to make it so you're working with playing cards or Tarot cards? With a few logical and UI changes, that's an achievable goal. Want to make your app all graphical and flashy with animations or backgrounds? Go for it. How about having multiple users use the same "table" together in real-time? Statistics, analysis, visualizations – the humble dice-roller is an excellent place to start.

Finally, a cheap or freemium app like this won't replace your day job, but going from zero to seeing your work on the App Store is incredibly motivational. Take what you've learned and start from the top with your idea.

On to the first iteration!

As we start this journey together, I thought I'd put together a game plan for how I approach this project, what to expect from each step of the process, and to serve as a reminder if I get distracted along the way. I'll update this page as we go along if any step seems to be dragging on or if I realize I forgot something important alomg the way.

Step One: The Bare Bones

We'll create the first iteration of our app using a modern front-end framework, starting with React. This will be a purely client-side version, and to be honest, it'll probably be pretty janky.

Step Two: Style Over Substance

Using the final product from Step One, we'll add styling and reorganize our app to make it beautiful on any device—well, "beautiful." Since having many different options here multiplies the work involved, we'll go through three styling options before settling on one.

• Vanilla CSS
• A UI Kit
• Tailwind CSS

Step Three: Function Over Form

We'll return to the functional side and start adding the parts of web applications that don't get top billing. We'll refine our application, separate our concerns, and prepare for the next step. This is where the scary shit starts, so we'll take it slow and do a lot of unnecessary logging to the console so it's clear what we're adding.

• Using SSO for authentication
• Reactive programming and observables
• Using browser storage
• Other refinements TBD

Step Four: Datalore

Before we jump to a public-facing app, we'll get down and dirty with exactly what our application will do and what we want (and don't want) people to do with it. We'll also think about our data and how to generate, store, and manage it. We'll compare the different approaches, choose one, and write up a plan. This is where we start to get serious!

• Key-Value Stores
• NoSQL
• SQL (starring Postgres)

Step Five: Protect & Server

We'll split our application into front and back ends (even if that distinction gets lost along the way ... we'll talk about it). We'll take our existing application and move our data to the server where it belongs using NextJS, the meta-framework related to React.

After this step, we'll start alternating installments: One strand will continue with our current app in React, the other beginning a grander vision in another framework: Svelte and SvelteKit.

Step Six: Deploy, Ahoy!

Deciding where and how to deploy our application. More TBD

Step Seven: Stores & Mores

TBD

Everyone has to start somewhere.

I spent many of the first years of my career as a developer flailing around like an inflatable man in front of a car dealership. I picked up bad habits, followed bad patterns, adopted bad technologies (Adobe Air, anyone?), and went down way too many dead ends.

Over the last 15 years – the section of my career where I could call myself a developer without worrying someone would check my ID and toss me out of the club – I've also prioritized mentoring others. Being a developer is one of the most rewarding things I can do with my time and energy. I try to fan those flames whenever I can in others, and I've been proud to be a part of several success stories.

Semicolonic is my attempt to take that mentorship on the road, if you will, for a wider audience. We'll start at a point where folks interested in becoming web developers can come along for the ride: Exploring the current Javascript frameworks (both client-side and server-side), comparing and contrasting.

Your feedback is part of the process. If I find an audience among folks who need to understand CSS or the basics of HTML, we'll also take some time to review that. Think of Semicolonic as the hip, cool TA in your self-taught developer journey.

OK, sleeves rolled up. Let's go.