Copy
Stay up to date with the latest news on React.
View this email in your browser

The React Newsletter

Hi <<First Name>>,
 
Why I'm using react-testing-library instead of Enzyme

Enzyme has been my weapon of choice since 2016 for testing my React components. What I liked the most with Enzyme was the isolation of the component when testing it using shallow rendering. I could focus on testing the component behaviour and checking that the correct props were passed down to the children (mostly using snapshot testing). That allowed me not to have to mock the children components, for instance for root components, and have tests that run quickly. So, I was only testing at the unit level, each component separately, and tested the big picture using Cypress (end to end testing).

It’s only when I started to use React 16.8 (“The One With Hooks”) that I looked at other testing libraries. The main reason was the non-possibility to test custom hooks with Enzyme and not being able to use shallow rendering. Which led me to be more curious with other solutions and to dig into react-testing-library finally.


Read more
 
Microfrontends — bringing JavaScript frameworks together (React, Angular, Vue etc)

Like most things in life, a variety of choices informs a toxic culture of mine is better than yours and you’re wrong and I’m right.

Since technology advancements have got us in this mess, is there any chance it could get us out of it as well?

Enter Microfrontends…


Read more
 
Scaling Applications with Microfrontends
Once upon a time, you had one Single Page Application using a Monolith Backend that relies on a Database. Then you started getting some users and suddenly you needed multiple instances of your Monolith Backend and more replicas of your Database. Your user base kept growing and also your development team was growing, so you split your Monolith backend into Microservices with their own Databases.

You’re very happy about the situation until you realize that the same problem you had on the backend it’s now on the frontend. Multiple teams are working on the same codebase, it’s hard to do frequent releases and there’re a lot of cross-team communications that slow things down.

At DAZN we battle-tested the Microfrontends architecture leveraging feature like blue-green deployments in the frontend, framework agnostic teams and drastically reduced cross-team dependencies.

Watch video
 
How we built a component library that people actually enjoy using

Sprout Social’s design system, Seeds, has done a lot of growing up since it launched in October of last year. When we launched, our system was home to four categories of guidelines and principles: Brand, Visual, Writing, and Product. A healthy showing, for sure, but something was suspiciously missing — components.

Sprout has had a React component library longer than it’s had a design system. We call ours Racine (after the avenue in Chicago where Sprout was once headquartered), and it has long been the source of truth for component patterns in our web app.

At its core, our component library was two things:

  1. A package of React components (built with Styled Components and Styled System) published to npm
  2. A website, built on Create React App, that acted as a local development environment for our developers and a documentation website for stakeholders across the company.

What began as a slim, hand-crafted tool slowly grew more bloated over time. Racine was passed around by developers who had the time to work on it, but there was no dedicated team to manage it. Eventually, neither the local development experience, nor the experience as a documentation site, were delightful for anyone. We realized the component library was holding us back more than it was helping us.


Read more
 
The 10 Component Commandments

Creating components that are used by a lot of people is hard. You have to think pretty carefully about what props you should accept, if those props are supposed to be part of a public API.

This article will give you a quick introduction to some best practices within API design in general, as well as the definite list of 10 practical commandments you can use to create components that your fellow developers will love to use.


Read more
 
Why I don't use web components

For my first post on dev.to I thought I'd write about a nice, safe topic that's free of controversy: web components.

I'm mostly writing this for my future self, so that I have something to point to next time someone asks why I'm a web component skeptic, and why Svelte doesn't compile to custom elements by default. (It can compile to CEs, and it can consume CEs as evidenced by its perfect score on Custom Elements Everywhere.)

None of this should be taken as criticism of the hard work that has been done on web components. It's possible that I have made some errors in this post, in which case I'd welcome corrections.

Nor am I saying that you shouldn't use web components. They do have valid use cases. I'm just explaining why I don't.


Read more
 
React video courses
Because I need to pay my bills 😉
 
Copyright © 2019 ABL - The Problem Solver, All rights reserved.


unsubscribe from this list    update subscription preferences 

Email Marketing Powered by Mailchimp