The time has come to sit down and actually write down the code. Going into the details of each line that makes TaskFight could make for its own series of articles, though. But overall, there are common steps to go through for each of the features.
When coding, it’ll help to think of TaskFight as two parts interacting with each other:
This split accommodates nicely the 6 parts thought-model for the features described in the previous article: storing data, reading the data & updating the data one one side, presenting read data, displaying interactive elements & reacting to interactions on the other.
But most importantly this split spreads the responsibilities of the code, so not everything is mixed up together. This means that if the computed rankings are wrong, it’s likely something in the domain logic that’s broken. Likewise, if nothing happens when tapping on one of the tasks, looking into the UI parts will be a good place to start.
Before going into writing, we need a closer look at the problems we’ll write the code to solve. And there are two kinds of problems we’ll encounter:
Ideally, we want to spend most of the time solving the first kind. These one bring most value to the users. However, without solving the second type, no app :(
The thing with the technical problems, though, is that there’s a chance that other apps would have had the same (or close) issue to solve. And fortunately, the developer community is big about sharing. We write technical articles to explain how we went about finding a solution for this or that. And even better, we share code (software libraries) for others to directly reuse in their apps.
Obviously, not all technical problems will have an off-the-shelf solution to grab. And most likely, the article or the library will need some configuration and adjustments to fit the project. But if the time spent looking for it, setting it up, as well as it complexity and the weight it adds to the project outweighs coming up with a new solution, it’ll be a massive time saver!
For TaskFight, there are two main things libraries are going to help with:
Each of the two parts above is a good place to start. I prefer starting with the UI bit. It’s nice to have something “tangible” quicker, but it’s not just that. It helps to avoid coding unnecessary stuff in the domain logic too, as you clearly see which functions it’ll need to provide to the UI. A bit more planning ahead would mitigate that if you were to start with the domain logic.
Making the UI will again be a matter of dividing things up. Each screen can be split up into smaller components with limited responsibilities. For the screen with the list of tasks, they would be:
Which would translate nicely to this HTML-like structure:
<TaskListScreen>
<AddTaskForm />
<TaskList />
</TaskListScreen>
Suddenly, the screen doesn’t look so daunting. The more complex structure of the form would be encapsulated in the AddTaskForm, which would resemble something like this:
<form onSubmit={addTask}>
<input type="text" name="task" />
<button>Add task</button>
</form>
This is not too bad either. Each small component will be given a limited list of tasks, to make it easier to implement. And then they’ll be composed to form bigger components to create the final screens providing more complex functionalities.
As we’ll divide the UI, 4 functions for the domain logic will emerge:
These are just the start of a series of step to repeat for coding the whole app:
addTask function prevents duplicate, and the TaskForm displays some feedback in that case. There’s often more than appears at first glance.After repeating this for all the features, the app is good to be transferred to the server and opened to the users. It should happen pretty soon now. Stay tuned!
Hope you enjoyed it. The journey is now over and the app will soon be released. You can subscribe to the newsletter to get notified when it'll get opened :)