Craft the Front-end
How should I implement that? Is it a good practice?
If you ever asked yourself such questions, this article (and the next ones 🤗) packed with real-life examples is definitely going to give you some answers!
The article is divided into three sections:
- Responsive design (CSS, TypeScript, and Jest),
- Object-oriented SCSS,
- Advanced testing in Jest.
Enjoy reading!
Responsive design
Let’s say you write an app with a different design for desktop and mobile devices. There is some content rendered only for screens smaller than 1024px
. When you check it manually, it looks like everything works perfectly. But it would be good to test it, wouldn’t it? 😉
You write tests for desktop and they are green! Yeah, sure they are, that’s you who wrote the code, and they are just testing some silly functionality. But how to test the mobile views?
Assume that the tests are written in Jest. You check the documentation and see that Jest by default sets the screen width to1024px
. Hmm, how to resize the screen for testing?
Fortunately, it is possible — check the TypeScript example below:
If you are not familiar with the responsive design, you can be wondering how it is even possible to show different things for different screen sizes. Well, there are two ways of doing that:
- code,
- CSS (or even better: SCSS).
Let’s consider the latter option — @media(max-width: _px) { ... }
. You might ask yourself:
Will the CSS file not become less readable due to media tags scattered all over it?
You are right — it probably will 😣 But it does not have to! The solution is to have more than one file, each of them containing only data relevant to the relevant screen width.
Did you like the SASS files above? I bet yes, but check the following section to become even more impressed! 🤩
Object-Oriented CSS
Does the title of this section sound a bit abstract to you? Just wait for the abstract class 😎
What is going on in the example below? Imagine you want to display some fruit. If it is ripe and tasty (or only ripe), it is colored with one solid color. However, if it is not yet ready for being consumed, it is marked with a dashed border and without a color inside.
See how we kept the code DRY incorporating inheritance and composition? Who said that the CSS (actually SCSS 😅) cannot be object-oriented?!
Advanced Testing
We began with testing, so let’s end the same way!
Sometimes it is expected from the code to throw an exception when something goes wrong. But how to test that such an error was in fact thrown? Actually, there are a couple of ways to do that. Let’s consider two of them:
It the first one, we explicitly catch the error and either pass or fail the test. It works, but does it mean we should use it? 🤔
In the second one, we make perfect use of the function from the Jest library. There is only one caveat — make sure you invoke the function in the expect statement! Otherwise, Jest is not going to catch the error for you.
In the example above a utility function was tested. Assume you use that function in some other class. How such a class should be tested? Should you care about correctness of the utility function? Well, you do not have to. The utility function is (or at least should be) tested separately.
So how can we make our tests independent of another module? We should mock it. To understand the idea better, let’s take a look at the example below 🧐
Because we do not test the Utils
module, we can assume it works correctly, so we can mock its behavior. Hence, we test the module we want in complete separation, without potential problems caused by an external module!
Thanks for reading! 👏👏👏