I like a lot of great tutorials on how to make different applications. Still, I was often confused when creating my own applications.

So I wrote this article to guide you through my thought process, and here’s how I planned and developed my own project.

Quick note before we begin: This article is not a “silver bullet” guide to creating any project. It’s just my personal way of getting the project done. It may or may not suit you.

There is no “right” way to build any app. Remember: all roads lead to Rome. (Unless, of course, you’re wearing a shiny ring on your way to Mordor, in which case, unfortunately, you only have one way.) (Translator: Lord of the Rings.)

I’m going to write the sample application code in react.js. I added a Code Sandbox and finished application at the end of this article.

Therefore, you also need to be familiar with setting up the React project. But don’t worry, the principles in this article still apply no matter what language you’re writing your application in.

OK, let’s get started. Today we are going to design a… TODO LIST!

Just kidding. We’re going to make a simple calculator.

“What does it do?” (What does it do?)

This is the first question I ask myself before starting any project. I want my calculator to:

  • Add, subtract, multiply and divide numbers
  • Display calculation results
  • To reset the display

That should be enough for now. Planning functionality in this way gives you an idea of what your application is going to do and starts to put you in the “scope.”

This approach also provides you with solid goals. Once you’ve implemented all the features, you’re done, and then you can start thinking about your next project — Huzzah! (Yeah!)

Otherwise, you might end up adding too many features and even seeing calculators in your sleep. Of course, you can keep adding features if you want. But make sure you’re working toward an end goal.

In the real world — depending on your role — there may be a customer or product that defines the “what does it do” part for you. Your job as a developer will break these requirements down into more detailed tasks, which we’ll cover later.

“What does it look like?” (What would it look like?)

Now that I have an idea of what it will do, THEN I start thinking about what it will look like.

If you’re struggling with design, you can do this in a number of ways:

  • Let’s look at some examples of similar applications
  • Browse CSS frames for available elements
  • Or use your imagination. (Not every project has to look “incredible.”)

I’m feeling particularly artistic today, so I’m going to use a quick wireframing to draw what I want the calculator to look like:

Ah! Excellent! I should be an artist.

So I have the feature list, and I have a portrait that van Gogh would be proud of.

In reality, when you’re working as part of a team, a designer might offer something similar. Or, better yet, you might get a working prototype that you can use.

“How do I position and style the elements?” (How do I position and design elements?)

I feel good about what my app should do and look like. Now it’s time to be more technical.

And I’m thinking, “OK, I’ve got some buttons and I’ve got a big monitor. How am I going to put them in a place?”

I like to think of implementing a design as a bit like building a house. Lay the foundation (layout), build the external structure (buttons, input boxes), then add the final touches (colors, ICONS, styles).

When it comes to layout, the first thing I think of is CSS Grid, Flexbox or frameworks (like Bootstrap). I’m going to use Flexbox because it’s responsive, so it’s very easy to arrange elements in a row, and I like this layout. This saves me having to install extra dependencies that we don’t need.

“How does it behave?” (How does it work?)

Now it’s time to think about how the application will work. This basically breaks down our functionality into more details to help design the code.

When I ask myself, I think about these things like this:

  • whenAppWhat happens when it loads?
  • What happens when the user clicks the button? Does the style change?
  • UIHow do you react to various user actions?

Another way to answer this question is to actually use an existing example.

Here’s a little task: Open the calculator on your computer and do something. Addition, multiplication, whatever.

As you perform the operation, see what happens and if you can capture as much information as possible.

Here’s what I found:

  • When the app loads, the display is set to “0” and all buttons are “deactivated.”
  • When the user clicks on a number, the display updates to the new value. The button clicked changes the style to indicate to the user whether the click was successful.
  • When the user clicks the operator, the selected operator indicates that it has been selected in some way.
  • If the operator has already been clicked and then the user clicks the number button, the display will reset to zero first before the user clicks the next number.
  • When the equal button is clicked, the calculation is performed using the initial number, the selected operator, and the next number entered.
  • When the user hits the clear button, the display resets to 0 and so does the entire app.

In reality, we don’t always have the luxury of an example or prototype. But as you get more experience, it becomes easier to implement wireframes or models. That’s why I’d like to suggest that beginners copy existing apps, because it gives you an example of practicing critical thinking and analysis.

But why do we have to go into detail? Good question. The answer is because computers are very smart, but also very stupid. (don’t believe it? Try to remove a random curly bracket from your code, it will get messy.

The instructions we give the computer have to be very specific. For example, looking back at the behavior above, clicking on a number can be different depending on whether the operator was clicked.

We humans know how calculators work, but for computers, we have to tell them.

“What will my code look like?” (What will my code look like?)

Just like I spent a while designing the UI, I will do the same for the code. This has many benefits:

  • Will make me think carefully about what components I need
  • Let me think about the workflow
  • This means writing code will be easier/faster because I have a plan
  • Identify problems and problem spots early

As I mentioned earlier, my goal for this project was to keep it simple, so I’ll stick with it. To start, I would keep everything in one component. However, I’ll start refactoring and splitting into components in the following cases:

  • Code grows to the point where it is difficult to manage or reason
  • There’s a lot of duplicate code
  • A single element on a page needs its own functionality and state

Have you ever finished a project and thought, “Oh, I forgot something, I have to redesign everything!” By planning ahead, you will avoid this pitfall. With that in mind, this is something I thought I would need. Don’t think about it all day. Find a balance between planning and getting started. Let’s break down the UI model into its parts and consider what code you’ll need.

The Display (Layout)

My display displays the current number to the user, so I need some status values. Clicking on nothing happens, then I don’t need anything in that location.

The number buttons

Because the number key affects the number displayed on the display, I need a function called by the onClick event to manage it. There is currently no need to store the selected number in the state.

The operator buttons

The operator button is an interesting button — when different things happen (remember our previous lesson about “How does it behave? “). Because I need to know the currently selected operator, I store it as a state value as well.

The equals buttons

The equal button should take the display value, operator, previous input value and evaluate the result. Simple!

Not exactly, we’ve got our first problem! Let’s review our behavior.

If the operator button is clicked and then the user clicks the number button, the display will reset first and then show the number that the user clicked.

When the user clicks on the operator and starts typing the next number, the first number the user enters into the display is reset — meaning our application doesn’t know what the first number is when the user clicks on the equal sign (I told you computers are stupid)! Let’s consider:

When the operator button is clicked, the display resets and updates with the next number entered by the user. Logically, it makes sense to store the previously displayed value when the operator is clicked. To do this, I need a function and a state value to store the display value of the click operator.

The clear button

This is the easy one — reset our status value to 0 to allow the user to use it again. I will need an onClick function associated with the button to handle this problem.

“What do I need to test? And what can go wrong?” What do I need to test? What could go wrong?)

Depending on who you’re talking to, you can test this in different ways. Some people like to do TDD (write tests first), others like to write them last. I’ll do it all, it depends on the project. But the main thing is, you have to write them at some point.

When I think about testing, I look at the following requirements. The first requirement (or feature) is:

  • The addition, subtraction, multiplication and division of numbers

So I need to test that this application can do these things. I won’t go into the details of how to write tests, but a good test case should cover:

  • Requirements and common use cases
  • Boundary conditions (such as user input 999999999999999999 + 99999999999999999999)
  • Error conditions and interrupt exceptions (such as the user trying to divide by zero)

“How many tests should I write?” That could be your next question. Unfortunately, there is no hard and fast indicator. You can have an infinite number of inputs. If you follow the points above, you’ll have a solid set of tests for any project.

Thinking about your tests early will help you consider possible errors in your code and provide insurance early in your design.

Let’s look at the code.

This is not a coding tutorial, so I won’t go into the details of each step in this article. See the code sandbox at the end for working examples, including code/demos for each of the steps outlined below. You can fork, run, break, and do whatever you want.

When writing code, we follow this plan:

  • The point is to use our wireframe as a reference to get the UI layout and elements first
  • Implementation logic (JS, time handlers, etc.)
  • Final touches
  • Remember to do the simplest thing to make everything work – no need to worry about refactoring and performance in the first place!

Step 1: Layout and basic UI elements

(Click the Step 1 button in the sandbox below to see a working example. See app-step-1.js to see the code!)

Keep in mind that we will start with the layout and put together the scaffolding we apply. This will include adding HTML and using Flexbox to locate our display and buttons. They can’t do anything, but they look good! Sort of.

Step 2: Add logic

(Click the Step 2 button in the sandbox below to see a working example. See app-step-2.js to see the code!)

We’ve finished planning this part, so let’s review it. In our “What would My code look like” section, we had to create a pair of different state objects and functions to handle events.

To do this, I started from “What will my code look like?” Select one item at a time from the list and refer to “How does it work?” Put it all together. I implemented the feature and tested it to see if it worked (usually automatically but manually). Such as:

The first item in the list is the display screen. So I’m going to add state variables and logic to this. Test that it works properly, then go to the number keys, and repeat. This is one of the benefits of writing tests in advance — you can run them frequently to make sure nothing breaks.

Step 3: Add bells and whistles

(Click the Step 3 button in the sandbox below to see a working example. See app-step-3.js to see the code!)

Great! We’re almost done! Now that the logic is working, we’ll now add some finer finger touches (round buttons, borders, larger display) to the app, and we’re done! Our basic calculator can now do something!

Step 4: Over to you!

I intentionally left something behind, so you can keep trying, if you want. Use the approach we’ve learned so far — think about behavior, what functionality/state objects you need, etc.

  • Our calculator doesn’t exactly match the wireframes design – can you add some color to the buttons? How about changing the color of the selected button before clicking?
  • No tests! See if you can add some.
  • There is some duplication of code — can you find a way to render buttons so that we don’t have to hard-code 16 button elements?
  • Error handling – non-existent! This is not good. What happens if you try to divide by zero? Or are your numbers wider than the display?
  • When the user starts typing a number, the previous ones are added to the display, for example000003This is not a good user experience, can you fix it?

The translator to summarize

How do I start writing my own application or project? If you’re having a hard time getting started, the authors of this article have given us a good idea to start with functionality, then look and feel, and then logic. Once these design features are complete, you can start refining your code and testing. Of course, as the author himself has said, this approach may or may not work for you, but the goal should be the same from the start. At the start of an application or project, we should not consider too much design specification and design patterns of these things, but to allow easy project, the structure is clear, can work, has a perfect test points and test cases, at the time of writing the code you will naturally involves the design principles and design patterns, these things, I am convinced that These things are already in your blood. After completing an application or project, we can take a look at our own code and then think about refactoring and abstracting middleware.

I hope you will have some enlightenment after reading this article.

link

Original address:

www.freecodecamp.org/news/a-walk…