As your application grows, you start to look for performance patterns to make it faster. On the way, you’ll find code splitting and lazy loading to be two of them that make your initial bundle smaller by deferring the loading of code chunks until needed.
When building applications you often come across the case where you need to design a list or search interface for the user. They usually manage lots of data, thus you need a way for the user to show it “in chunks” so that we keep the application performance and the data organized.
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.