In the CSS world, we can see plenty of great preprocessors that improve the language, being SASS/SCSS, LESS and PostCSS the most common among them. SASS seems to be still the most popular and used solution by the date of writing, and that's no surprise since it's fully featured and extends the CSS language with an easy to understand syntax.
One of the features that amazed me about Jest is snapshot testing. It’s not necessarily a Jest-only feature, but more of a technique and concept. Anyways, the first time I’ve seen it was in Jest.
Test doubles, spies, and mocking, all sound intriguing, but what do they actually mean? Do I really need to spy on my code, or mock it? Let's find out!
So far we’ve build the router in a component and a history module within the source code of our app. The problem of it is that the router is tied to the app, specially because the routes are defined within the
That could be improved by moving out the routes from the component and passing them as a parameter. But still, the developer must import the
AppRouter component and the
history.js module and use it around.
Lazy Loading and Code Splitting are two of the main points of the PRPL Pattern, a pattern named by Google which intent is to to provide some structure to make the initial load of a Progressive Web App (PWA) as fast as possible, boosting the performance.
At this point, the router doesn't work as a Single Page App (SPA) router, since it assigns a new route to
window.location directly, which performs a hard reload.
Probably you've been using routers in the frontend world for a while, but... have you ever written one by yourself? Do you know the foundations of a router? It might seem like it just works, but under the hood a router must take care of several things.