DEV Community: Codux

React: Lessons from the Trenches - useEffect x Infinity

Peter Shershov — Thu, 23 Mar 2023 13:21:46 +0000

Hey! My name is Peter and I’m a software team-lead, working on Codux by Wix.com.

I’ve been building user interfaces with React for more than 6 years and have made tons of mistakes during this time. From memoizing almost everything in my component to drilling props like I’m looking for oil — I fell into every trap. I’ll try to break down a couple of issues I’ve dealt with and hopefully, it’ll help you jump over pitfalls in the future. Some articles in this series will address bad practices and design concerns while others focus on specific bugs in special use cases.

Let’s start with a prevalent one, updating a state within useEffect can cause an infinite loop by re-rendering the component to infinity.

What we see above is a warning (“Maximum update depth exceeded”) indicating that there’s an operation occurring too many times, one after the other.

This can happen in several scenarios.



const [superheroes, setSuperheroes] = useState([]);

const updateSuperheroes = () => {
   const newSuperhero = generateSuperhero();
   setSuperheroes([...superheroes, newSuperhero]);
};

useEffect(() => {
  updateSuperheroes();
}, [updateSuperheroes]);

Consider the example above.
First of all, we know that every state update triggers a re-render, meaning that the code written inside the component function gets executed. We also know that useEffect executes when one of two conditions is met after a render:

A component is mounted
One of the dependencies (declared in useEffect’s dependency array) has changed.

Keep in mind that useEffect’s dependency array should reflect the usage. Omitting a dependency that is used inside the useEffect can cause stale data issues, while including a dependency that does not impact the effect can cause unnecessary re-renders.

With these in mind, we can start debugging the code above.
We can see that updateSuperheroes() is executed inside a useEffect, which requires us to declare it as a dependency.
updateSuperheroes adds superheroes to the state by creating a copy of the superheroes array and adding new entries to it.

When the superheroes state gets updated, the component re-renders with the new state, the updateSuperheroes function is created anew which causes useEffect to trigger, restarting this cycle.

What to do?

To prevent something from being created multiple times over multiple renders we often take advantage of memoization. React offers several tools to memoize our functions and values. useCallback is used for functions and useMemo is used for values such as objects or arrays.

Primitives that require a minimal computation don't need to be memoized since they are easily comparable, on the other hand, objects, functions, arrays and other complex data structures, could be created anew with every render if declared inside the component.

In our case, updateSuperheroes is a function, and should be memoized, therefore, we should leverage useCallback.



const [superheroes, setSuperheroes] = useState([]);

const updateSuperheroes = useCallback(() => {
   const newSuperhero = generateSuperhero();
   setSuperheroes([...superheroes, newSuperhero]);
}, [superheroes]);

useEffect(() => {
  updateSuperheroes();
}, [updateSuperheroes]);

But this is not enough. We can see that useCallback has a dependency on superheroes that gets changed on every run of useEffect, making this memoization redundant. For such cases, React provides us with another way to update the state without being dependent on the value.

Every state setter can get two types of the first argument.

One, a new state:



const [state, setState] = useState([])
// ...
setState([...state, 'something new']);

Or two, a function that gets the previous state as an argument and returns a new state.



const [state, setState] = useState([])
// ...
setState(previousState => [...previousState, 'something new']);

Using the latter way in our example will fix the infinite loop since there is no dependency on the state anymore. It will trigger only when the component mounts.



const [superheroes, setSuperheroes] = useState([]);

const updateSuperheroes = useCallback(() => {
   const newSuperhero = generateSuperhero();
   setSuperheroes((previousSuperheroes) => [
      ...previousSuperheroes,
      newSuperhero
   ]);
}, []);

useEffect(() => {
  updateSuperheroes();
}, [updateSuperheroes]);

In some cases, you can extract values to an outer scope (outside of the component) when a value is not dependent on any specific component code.

For example, instead of:



const emptyObject = useMemo(() => ({}, []);

Move emptyObject outside of the component code:



const emptyObject = {}

function Superheroes() {
// ...
}

This will prevent the creation of a new object instance for every render without the need to memoize it over time.

What can be so complex?

Now that we know how to handle the simple case of a state update within a useEffect, let’s delve into the more complex scenarios.

In the example above we could very easily tell which dependency in our useEffect is causing the infinite loop. Debugging more complex cases where useEffect has a large number of dependencies (and each one of them might have its own set of dependencies) is a bit harder. Finding the culprit and maintaining this code in general requires more effort.

I’ve seen colossal dependency arrays across many projects, and here are a couple of recommendations for how to deal with them.

1. Separate your gigantic `useEffect` into a few smaller ones



useEffect(() => {
   // ...
}, [
   peopleProvider,
   engineersProvider,
   doctorsProvider,
   generateUniqueId,
   initializeApp
]);

Converting this example, where a useEffect gets a large number of possibly non-related dependencies, into this:



useEffect(() => {
   // ...
}, [peopleProvider]);

useEffect(() => {
   // ...
}, [engineersProvider]);

useEffect(() => {
   // ...
}, [doctorsProvider]);

useEffect(() => {
   // ...
}, [generateUniqueId, initializeApp]);

This way we can scope our side effects into separate, smaller useEffect declarations to prevent triggering irrelevant handlers.
In other words, updated dependencies will not trigger a side effect or a state update for a non-relevant functionality.

2. Debug the dependencies that are changing on every render

If you still couldn’t find the main cause of an infinite render and you still don’t know which state gets updated and what handler is causing it, I recommend implementing or using a helper hook (such as this) that logs the changed dependencies for each render.



useEffect(() => {
   // ...
}, [
   peopleProvider,
   engineersProvider,
   doctorsProvider,
   generateUniqueId,
   initializeApp
]);

useTraceUpdate({
   peopleProvider,
   engineersProvider,
   doctorsProvider,
   generateUniqueId,
   initializeApp
});

This will log only the changed values, indicating which dependency is changing every render leading to an infinite loop.

Conclusion

Fixing and avoiding useEffect’s infinite renders can be achieved by applying the following measures:

Keep your dependency arrays short and concise. Scope the useEffect you’re creating to a specific minimal context and avoid mixing dependencies that have different intents.
Memoize complex values and functions passed to your hooks and components.
Avoid depending on a state and setting it in the same useEffect, this is a very fragile situation that can break easily. If you must have such a case, you can take advantage of the option to set the state using a function provided to setState and not be dependent on the previous value.
Find the always-changing dependency (the one that is causing the infinite render) by debugging your dependencies. Try locating the value that is causing the infinite renders and memoize it correctly.

I hope you've found this article helpful, and I look forward to see y'all at the next one!

Experiments with the JavaScript Garbage Collector

Alexey Lebedev — Thu, 23 Feb 2023 17:39:47 +0000

Memory leaks in web applications are widespread and notoriously difficult to debug. If we want to avoid them, it helps to understand how the garbage collector decides what objects can and cannot be collected. In this article we'll take a look at a few scenarios where its behavior might surprise you.

If you're unfamiliar with the basics of garbage collection, a good starting point would be A Crash Course in Memory Management by Lin Clark or Memory Management on MDN. Consider reading one of those before continuing.

Detecting Object Disposal

Recently I've learned that JavaScript provides a class called FinalizationRegistry that allows you to programmatically detect when an object is garbage-collected. It's available in all major web browsers and Node.js.

A basic usage example:



const registry = new FinalizationRegistry(message => console.log(message));

function example() {
    const x = {};
    registry.register(x, 'x has been collected');
}

example();

// Some time later: "x has been collected"

When the example() function returns, the object referenced by x is no longer reachable and can be disposed of.

Most likely, though, it won't be disposed immediately. The engine can decide to handle more important tasks first, or to wait for more objects to become unreachable and then dispose of them in bulk. But you can force garbage collection by clicking the little trash icon in the DevTools ➵ Memory tab. Node.js doesn't have a trash icon, but it provides a global gc() function when launched with the --expose-gc flag.

With FinalizationRegistry in my bag of tools, I decided to examine a few scenarios where I wasn't sure how the garbage collector was going to behave. I encourage you to look at the examples below and make your own predictions about how they're going to behave.

Example 1: Nested Objects



const registry = new FinalizationRegistry(message => console.log(message));

function example() {
    const x = {};
    const y = {};
    const z = { x, y };

    registry.register(x, 'x has been collected');
    registry.register(y, 'y has been collected');
    registry.register(z, 'z has been collected');

    globalThis.temp = x;
}

example();

Here, even though the variable x no longer exists after the example() function has returned, the object referenced by x is still being held by the globalThis.temp variable. z and y on the other hand can no longer be reached from the global object or the execution stack, and will be collected. If we now run globalThis.temp = undefined, the object previously known as x will be collected as well. No surprises here.

Example 2: Closures



const registry = new FinalizationRegistry(message => console.log(message));

function example() {
    const x = {};
    const y = {};
    const z = { x, y };

    registry.register(x, 'x has been collected');
    registry.register(y, 'y has been collected');
    registry.register(z, 'z has been collected');

    globalThis.temp = () => z.x;
}

example();

In this example we can still reach x by calling globalThis.temp(). We can no longer reach z or y. But what's this, despite no longer being reachable, z and y are not getting collected.

A possible theory is that since z.x is a property lookup, the engine doesn't really know if it can replace the lookup with a direct reference to x. For example, what if x is a getter. So the engine is forced to keep the reference to z, and consequently to y. To test this theory, let's modify the example: globalThis.temp = () => { z; };. Now there's clearly no way to reach z, but it's still not getting collected.

What I think is happening is that the garbage collector only pays attention to the fact that z is in the lexical scope of the closure assigned to temp, and doesn't look any further than that. Traversing the entire object graph and marking objects that are still "alive" is a performance-critical operation that needs to be fast. Even though the garbage collector could theoretically figure out that z is not used, that would be expensive. And not particularly useful, since your code doesn't typically contain variables that are just chilling in there.

Example 3: Eval



const registry = new FinalizationRegistry(message => console.log(message));

function example() {
    const x = {};

    registry.register(x, 'x has been collected');

    globalThis.temp = (string) => eval(string);
}

example();

Here we can still reach x from the global scope by calling temp('x'). The engine cannot safely collect any objects within the lexical scope of eval. And it doesn't even try to analyze what arguments the eval receives. Even something innocent like globalThis.temp = () => eval(1) would prevent garbage collection.

What if eval is hiding behind an alias, e.g. globalThis.exec = eval? Or what if it's used without being ever mentioned explicitly? E.g.:



console.log.constructor('alert(1)')(); // opens an alert box

Does it mean that every function call is a suspect, and nothing ever can be safely collected? Fortunately, no. JavaScript makes a distinction between direct and indirect eval. Only when you directly call eval(string) it will execute the code in the current lexical scope. But anything even a tiny bit less direct, such as eval?.(string), will execute the code in the global scope, and it won't have access to the enclosing function's variables.

Example 4: DOM Elements



const registry = new FinalizationRegistry(message => console.log(message));

function example() {
    const x = document.createElement('div');
    const y = document.createElement('div');
    const z = document.createElement('div');

    z.append(x);
    z.append(y);

    registry.register(x, 'x has been collected');
    registry.register(y, 'y has been collected');
    registry.register(z, 'z has been collected');

    globalThis.temp = x;
}

example();

This example is somewhat similar to the first one, but it uses DOM elements instead of plain objects. Unlike plain objects, DOM elements have links to their parents and siblings. You can reach z through temp.parentElement, and y through temp.nextSibling. So all three elements will stay alive.

Now if we execute temp.remove(), y and z will be collected because x has been detached from its parent. But x will not be collected because it's still referenced by temp.

Example 5: Promises

Warning: this example is a more complex one, showcasing a scenario involving asynchronous operations and promises. Feel free to skip it, and jump to the summary below.

What happens to promises that are never resolved or rejected? Do they keep floating in memory with the entire chain of .then's attached to them?

As a realistic example, here's a common anti-pattern in React projects:



function MyComponent() {
    const isMounted = useIsMounted();
    const [status, setStatus] = useState('');

    useEffect(async () => {
        await asyncOperation();
        if (isMounted()) {
            setStatus('Great success');
        }
    }, []);

    return <div>{status}</div>;
}

If asyncOperation() never settles, what's going to happen to the effect function? Will it keep waiting for the promise even after the component has unmounted? Will it keep isMounted and setStatus alive?

Let's reduce this example to a more basic form that doesn't require React:



const registry = new FinalizationRegistry(message => console.log(message));

function asyncOperation() {
    return new Promise((resolve, reject) => {
        /* never settles */
    });
}

function example() {
    const x = {};
    registry.register(x, 'x has been collected');
    asyncOperation().then(() => console.log(x));
}

example();

Previously we saw that the garbage collector doesn't try to perform any kind of sophisticated analysis, and merely follows pointers from object to object to determine their "liveness". So it might come as a surprise that in this case x is going to be collected!

Let's take a look at how this example might look when something is still holding a reference to the Promise resolve. In a real-world scenario this could be setTimeout() or fetch().



const registry = new FinalizationRegistry(message => console.log(message));

function asyncOperation() {
    return new Promise((resolve) => {
        globalThis.temp = resolve;
    });
}

function example() {
    const x = {};
    registry.register(x, 'x has been collected');
    asyncOperation().then(() => console.log(x));
}

example();

Here globalThis keeps temp alive, which keeps resolve alive, which keeps .then(...) callback alive, which keeps x alive. As soon as we execute globalThis.temp = undefined, x can be collected. By the way, saving a reference to the promise itself wouldn't prevent x from being collected.

Going back to the React example: if something is still holding a reference to the Promise resolve, the effect and everything in its lexical scope will stay alive even after the component has unmounted. It will be collected when the promise settles, or when the garbage collector can no longer trace the path to the resolve and reject of the promise.

In conclusion

In this article we've taken a look at FinalizationRegistry and how it can be used to detect when objects are collected. We also saw that sometimes the garbage collector is unable to reclaim memory even when it would be safe to do so. Which is why it's helpful to be aware of what it can and cannot do.

It's worth noting that different JavaScript engines and even different versions of the same engine can have wildly different implementations of a garbage collector, and externally observable differences between those.

In fact, the ECMAScript specification doesn't even require implementations to have a garbage collector, let alone prescribe a certain behavior.

However, all of the examples above were verified to work the same in V8 (Chrome), JavaScriptCore (Safari), and Gecko (Firefox).

The Future of CSS

Vlad — Thu, 09 Feb 2023 11:58:44 +0000

I have to admit: I don’t always have time to keep up with all the new CSS technologies, and I don’t always know which ones are worth my time.

To organize my thoughts, I produced an overview of all the major CSS technologies that are gaining popularity today and might still be relevant tomorrow: CSS-in-JS, Component-Oriented CSS*, and Utility First CSS.

I wrote about the big ideas behind them and the consequences of these ideas for code architecture, performance, and dev velocity.

You can try all the code examples via Codux by clicking here.

Component Oriented CSS: A term I coined, it refers to CSS frameworks, mostly preprocessors, that scope CSS locally, such as Stylable, or CSS Modules.

Vanilla CSS

CSS (Cascading Style Sheets) was initially released in 1996 during the Browser wars: Microsoft's Internet Explorer and Netscape Navigator. Each tried to define the web, which, at the time, was mostly static pages that displayed data.

One of the great advantages of CSS was the way styles “cascaded” from a parent to affect all of its children. This worked very well for the relatively small projects that existed in 1996 because it reduced duplication, made CSS easy to understand, and the inheritance easy to trace.

However, as projects grow in complexity, cascading becomes a liability; CSS rules often depend on the HTML structure, so every change in either requires changes in both. In addition, a small change in any rule can have unintended consequences on other pages due to global scope.

Using preprocessors like SASS or less and naming conventions like BEM can help organize a team’s code, but modern technologies can achieve better results with relative ease.

CSS-in-JS

Styled Components

Styled Components is a package that is installed using the package manager.

Button component is created by providing the HTML tag (button), and the style is provided as a string using a tagged template string. Inside, Styled-Components creates a unique className for the new Button Component and adds the className to the CSSOM*

Finally, styled.button returns a new component that uses the newly created style so that it can be used.

Try it out with Codux

CSSOM (CSS Object Model) is like the DOM, but for CSS, it allows adding CSS at runtime.

Emotion

Emotion is also a package that can be installed using the package manager. It works similarly to Styled-Components: the CSS prop is replaced with a uniquely generated className, and the style is added to the CSSOM.

By now, most libraries that allow CSS-in-js support both syntaxes.

The tagged-template-string format is useful because we can directly load legacy CSS from files, but it doesn’t support any syntax highlighting and code completion supported by the CSS prop out of the box.

Try it out with Codux

CSS-in-JS Advantages

Local scoping, since a unique className is generated for each component, the styling is now scoped to the component, and styles will no longer override each other simply because they are no longer global. In other words: these components can be extended but not modified from the outside.
Global scoping (cascading) was essential for CSS to avoid code duplication, instead sharing is easy because this is javascript code
The main building block of our app is now the component. This no longer feels like regular CSS. Instead, it becomes functional programming: the styling of a component is now an integral part of it, and they are both encapsulated into a single unit that exposes an API that can be reused.
This is javascript code, making it much easier to apply complex logic to your style rules, create dynamic interfaces, and reuse code.

CSS-in-JS Disadvantages

Loss of separation of concerns, CSS was designed so that content would be separated from presentation, with CSS-in-js component logic, animations, themes, and layouts all mixed together in the component; when not carefully managed, this could lead to unmaintainable code.
Browsers can render regular CSS much faster than styling that requires code to run; this can be alleviated by separating the critical CSS needed to load the user’s initial viewport and is further helped by server-side rendering.
An Extra layer of complexity needs to be set up and maintained and requires a steeper learning curve than vanilla CSS. This may be worth it for teams working on relatively large projects but can be detrimental in smaller ones.

Side Note - Vanilla Extract

This is a newer solution, which I have yet to try out extensively, but, after reading this article, a friend recommended that I also mention Vanilla Extract.
Vanilla Extract "uses TypeScript as a preprocessor" so it looks like CSS, but it's written in TypeScript, and so it requires learning a new Syntax.

It offers some of the runtime advantages CSS-in-JS has through css variables and classes, but unlike CSS-in-JS it's very fast because it generates atomic static CSS in build-time.
Vanilla Extract is still very new, so it doesn't enjoy the popularity some of the other frameworks do, but it is definitely on my watch list.

Component-Oriented CSS

keep everything we liked about CSS, and build upon the good work that the styles-in-JS community was producing. So, while we’re bullish about our approach and firmly defend the virtues of CSS, we owe a debt of gratitude to those folks pushing the boundaries in the other direction. Thanks, friends! 👬👫👭 — css modules team

CSS Modules

CSS Modules is a pre-processing step: by default, styles are scoped locally to the current component, and the transpiler ensures no conflicts.

Let’s see how it works. First, we add a button.css, just like with good old CSS.

Next, we import styles from the CSS we just created and apply classNames from it to our JSX:

The transpiler will make these styles locally scoped, and the result looks something like this:

Avoiding Code Duplication

By scoping locally, we sidestep the global scope issue but lose some of the advantages gained by cascading. Instead, to avoid code duplication, we use the composes keyword:
Let’s say we want a cancel button that is the same but with a different text color:

CSS modules adds both classNames to the component.

Stylable

CSS Modules helps manage large CSS projects by adding namespaces. Stylable is a CSS preprocessor that takes it even further by adding a type system.
Stylable exposes an API that can be styled, meaning selector issues are visible in build-time rather than run-time. For example, you’ll see it in the IDE if a button no longer supports an icon. Every developer knows that detecting and fixing a bug costs exponentially more during acceptance testing than during coding.
Stylable files look very similar to CSS files, but they are scoped:

In addition, because we now have an elaborate type system, we can now extend this button from parent components; for example, this could be a dialog containing our button:

Try it out with Codux

Component Oriented CSS Advantages

We can “compose” some of the CSS-in-JS advantages here: local scoping, composition, and the main building block of our project is still the component. That’s why I called it “component oriented.”
Concerns are separated, just like with CSS: themes and layouts are, by default, separated from the component without the need to manage them carefully.
Runtime performance is not affected, unlike CSS-in-JS, which executes in runtime and potentially slows down your app; this is a preprocessing step, resulting in plain CSS, which the browser is already heavily optimized for.

Component-Oriented CSS Disadvantages

No longer dynamic, complex logic is more challenging to implement; some styling features can’t be implemented without JS.
An extra layer of complexity, though with a gentler learning curve than what CSS-in-JS offers.

Utility First CSS

The idea is to have reusable, tiny classes like flex,pt-4, text-center, and rotate-90 that can be composed and used in any component.

Consequentially, around 90%-95% of most projects’ CSS can be translated into these atoms. For example, the component below has the following HTML code:

Utility-First CSS Advantages

HTML is now dependent on CSS; it has to know that certain CSS classes exist and how to combine them properly, making the CSS completely independent of the HTML and allowing programmers to quickly iterate on the design system regardless of the content. Smooth Iterations mean fast improvements and sleek products; that’s why Utility-First CSS results in some of the best component libraries. Check out Tailwind, and Bootstrap
The design system is more consistent, border-dark-soft, will always have the same color and width, and can be easily changed in all places. However, this can easily be achieved using composition and variables.
CSS files are much smaller. CSS usually grows linearly with project size: more components mean more classes and larger files, while utility-first CSS grows logarithmically with project size: border-dark-soft is defined once and used many times

Utility-First CSS Disadvantages

CSS was designed to be independent of HTML, that’s why we name classes based on content: button, author-bio, etc., or in other words, CSS is dependent on HTML and needs to know what classes were used. At the end of the day, the more volatile parts of our software (that change the most) should depend on the ones that change the least: in most projects, users like features and functionality (e.g., components) to be continually added, but they like the design-system to stay the same.
The naming convention requires a learning curve: what is py-2? We end up with these long unreadable classes: py-2 px-4 border-r border-dark-soft, that are hard to learn and difficult to understand.
Adds another layer of complexity to our stack, sometimes requiring setting up the naming conventions and adding a post-CSS processor to minify the result.

At the end of the day…

CSS has a fascinating future ahead of it. These technologies are here to stay, grow, and become easier to use. However, teams must be careful when selecting a specific technology over others. In general:

CSS-in-JS is worth the performance hit when complex logic is associated with styling.
Component Oriented CSS is perfect for organizing large projects, with many independent components.
Utility-First CSS seems to produce the best-looking interfaces with the least amount of effort, this makes a lot of sense: if the CSS is decoupled from the component structure, it can be iterated upon frequently.

Flaky Tests, and How to Deal with Them

Yarden Porat — Thu, 26 Jan 2023 15:45:35 +0000

Intro

Hey! My name is Yarden Porat, and in this article, I will explain what flaky tests are, their costs, their causes, and how they harm your work and organization. Once we have that figured out, I will share our strategy and tools we have developed in-house for dealing with test flakiness at Wix and how we avoid their costs.

What is a flaky test?

A flaky test is an automated test with a non-deterministic result. This is a way of saying that a test sometimes passes and sometimes doesn’t, inconsistently, without any code changes.

How often does it fail?

Beautifully depicted in this article, if a single test has a failure rate of 0.05% (0.0005), and you have 100 of these tests in your test suite, it would have a success rate of 95.12%= 0.9995¹⁰⁰.

But what happens when you have thousands of these tests? A 60.64% success rate (0.9995^1,000). It’s easy to calculate the significant impact of even a low failure rate on large scale tested applications.

But… What’s the problem? Just rerun the tests!

There are some really bad implications of ignoring flaky tests. Let's go over some of the most common ones, from least important to most.

1. Wasted CI minutes (Hours? Days? Weeks?)

Consider the following scenario:

You are a developer working in a team. There’s a new feature you’ve been developing for several days, and you opened a pull request wanting to merge it into the project.

Now, your company works in a modern development workflow and runs automated tests on your code changes using your CI system. All of the product’s tests ran and failed on a test entirely unrelated to the changes you introduced.

Since you are aware of the code changes you have made, and you know that this project has issues with non-deterministic tests, you therefore know the failing test is not your fault.

So, you rerun the test, and it passes.

If you don’t know your project has an issue with non-deterministic tests, you’ll probably waste even more time investigating.

The problem is that this time accumulates. The longer the test workflows take, the more time is wasted—but how much time? This can be measured, assuming you track your CI test results.

You can easily calculate the CI time wasted due to flakiness by summing up the CI time of a workflow run that had a non-deterministic result. For example:

#	commit	workflow_name	os	result	duration
1	9f3e679	test-part-1	linux	success	10
2	9f3e679	test-part-1	linux	fail	7

Run identifier: commit + workflow_name + os

That’s 7 minutes of CI time wasted!

2. Wasted development time

When a developer reruns a test, they are forced to wait (again) for the build and test time. Precious developer time is being lost.

Even if we assume that a developer utilizes this wait time for other tasks, we still have 2 major drawbacks:
Loss of immediate feedback (long feedback loop).
Context switching—which eats away at focus and productivity.

Unfortunately, this wasted time is much harder to measure.

3. Flaky product behavior (or flaky implementation)

Sometimes a flaky test is only a symptom of a non-deterministic implementation.

The same race condition that can cause test flakiness can do the same in a feature’s implementation, thus causing flaky product behavior in production.

4. Alert fatigue

A common phenomenon in flaky test workflow is the loss of trust in the feedback you are getting. Consider this scenario:

You push your new code
Workflow tests run and fail
“Oh it's that annoying flakiness again; we should fix it sometime”
Rerun workflow, tests run and fail
“D*%N FLAKINESS”
Rerun workflow, tests run and fail
Realizing that it was actually my code changes that had failed the tests
Go back to step 1

This harms development velocity and the developer’s experience. In an environment where it's not mandatory for tests to pass to merge a pull request, it is not uncommon for changes to merge even though they are breaking some product and tested behavior.

What's lost?

Money (Developer time, CI time)
Development velocity
Confidence in tests (regressing to manual testing)
Product quality
Developer experience

Causes of test flakiness

So now that we know the price and the pain, here are some of the causes of test flakiness.

1. Poorly written test code

For example, interacting with DOM elements that are not yet ready, or improper use of waitFor functions. This is the most common case where testing is done incorrectly. Sometimes, powerful development machines (a.k.a, your local computer) hide race conditions in a test, which ends up failing on CI machines.

2. Poorly written application code

As mentioned above, sometimes the application code itself introduces a flaky behavior. These cases are much harder to detect and debug. It could be related to communications, asynchronous code, or many other alternatives.

3. Infrastructural causes

There are various environmental causes to blame, and they are the immediate culprit for those who write flaky tests. Such causes may be:

Network issues: loss of connectivity, slow connection, etc.
Hardware issues: low-performance shared virtual machines, which stress existing race conditions
External dependencies: package manager (npm\yarn), runtime setup (i.e. Node, and other dependencies, which also suffer from some level of flakiness

4. Test tools that are prone to flakiness

In our experience tests which use a browser are more prone to flakiness. One reason is that the browser itself is a complex piece of software with many dependencies, and it can be affected by a variety of factors - its version, operating system, and other specific configurations of the machine it is running on.

Key takeaways up to this point

Here are some points I think you should keep in mind:

Flaky tests could occur due to many reasons and various causes. Some are test related, some production-code related, others from the infrastructure and development environment.
They have direct and indirect implications on the development process—both technical and psychological.
Flaky tests reduce development speed and quality if left untreated.

How to deal with flaky tests?

1. Collect data

It is much easier to communicate the costs of flakiness to your team or organization if you have data to back you up.

2. Analyze it

Workflow reruns per day bar graph

A bar graph that represents the overall flakiness and displays the total number of times a workflow has been restarted.
It helps us understand the scale of the flakiness problem and the lack of developer trust in the tests/CI.

At Codux we chose to count any case of workflow rerun, but you can also create a subset of this graph that shows reruns that never succeeded, which could better depict the lack of trust in your tests/CI.

This is a general index that tells if your data correlates with your general feel of flakiness. We don’t derive tasks from it.

We count rerun by identifying the commit, branch, OS, and workflow name. We call it an “entity” and count its total occurrences minus one.

Fail rate table

This is a table that calculates a test’s fail rate out of its total runs. We collect data from all branches, including development branches, and present only tests that have failed on 3 branches or more, with a minimum number of total runs.

This table helps us find the current culprits tests. A Flaky test that fails over an arbitrary percentage of your choice (we chose 5%), is skipped, documented, and assigned to the relevant developer. This process occurs 1-2 times a week.

This process requires reasoning and shouldn’t, in our opinion, be done automatically — for example:

Some features have a low number of tests, so you probably wouldn’t want to lose coverage, and you might prefer, or should, add a retry on those tests.
Some tests are more prone to failure (during development), such as end-to-end tests, so it might indicate they have a higher fail rate than they actually do.

Fail by test scatter plot (Environmental factors)

We’ve created a plot similar to Spotify’s Odeneye. This plot helps us realize if there are some environmental or infrastructural problems. If you suspect your infrastructure is causing flakiness, try creating this dashboard.

_
Horizontal lines indicate that a test is flaky. Vertical lines indicate an issue external to the test because it shows multiple test failures in the same timeframe. _

3. Run new tests multiple times

After noticing that newly created tests are flaky and require adjustments, we have decided to raise the bar for newly created tests and created “check-new-flaky” — a CLI tool that detects new tests and runs them multiple times.

It detects new tests by running our test runner (mocha) programmatically, recursively extracting test names on the branch, and comparing them to master.

Checking newly created tests reduced the new flaky tests added to the application and the need to refactor them significantly.

Some more benefits that we got:

Faster feedback loop: This test workflow runs your new tests immediately, thus letting you know if it passes without waiting for their turn within the entire test suite
Another OS is running your test: All our tests are running on Linux, while tests/features which are considered to be operating system sensitive, also run on Windows. Using the check-new-flaky CLI, we sometimes get an indication that a test we thought wasn’t OS sensitive is actually sensitive or broken for the other operating system.

4. Set a bar for when a test isn’t flaky

At first, it wasn't really clear to a developer when he fixed a flaky test. Developers would usually run a test 2-10 times before it would be labeled as not flaky and get merged to master.

Once we declared war on test flakiness, the bar would be set to 100 consecutive runs.

There are many ways to run a test multiple times — we used parts from the above CLI (check-new-flaky) and made it accessible via our GitHub bot.

Does your test only fail when running on CI?

CI machines usually have reduced performance compared to your local development machine, thus most race conditions only show once tests are running on the CI.

Helping tests fail on your local machine

One tool that we have found to be helpful is CPU throttling emulation.
We use Playwright for integration and end-to-end browser tests. It emulates slow CPUs using the Chrome Devtools Protocol (experimental feature).

  import type { ChromiumBrowserContext } from 'playwright-core';
   ...
   const client = await (page.context() as ChromiumBrowserContext).newCDPSession(page);
   await client.send('Emulation.setCPUThrottlingRate', { rate: 2 });

Rate is the slowdown factor (1 is no throttle, 2 is 2x slowdown)

Find out what’s going on with a test on the CI

Many testing tools today allow you to take some recordings of your tests.
Playwright released a tracing feature on version 1.12, which records the test flow and provides us with screenshots and DOM snapshots. Since we had a significant issue with flaky tests, we immediately integrated this feature into our testing utils, allowing developers to record runs.

We send CI tracing to a dedicated Slack channel for ease of use.

This feature is super helpful when you have no clue why the test is failing on CI. Tracing helped us catch some unimaginable bugs that we wouldn't have caught otherwise.

Stop using ElementHandles. Start using Playwright Locators

Following the release of Playwright Locators and ElementHandle being discouraged from use, we decided to migrate our test kits and test drivers to Locators to enjoy the benefits given to us by this new API: actionability check, more strictness (detailed below), and in our React application - reduced flakiness.

From our experience, we can say that simply replacing ElementHandles with Locators in a test can resolve flakiness by itself.

What's wrong with ElementHandles?

Each ElementHandle refers to an actual specific DOM node. React, when trying to reconcile changes, might replace these referred DOM nodes. This is happening due to changes or as a result of components being unmounted and remounted again, making the referenced ElementHandle irrelevant. Keeping references to specific DOM nodes is not really needed because we usually get those references with selectors — which are agnostic to specific DOM nodes.

How Locators help us to get the correct DOM node

Locators keep the selector itself rather than a reference to a specific DOM node.
Upon action (e.g .click()) the locator:
- Uses the selector to query the DOM node relevant for that try
- Verifies it is actionable (attached, clickable, etc.)
- Validates there is no single-multiple mismatch.
- Repeats the process until it succeeds.

The actionability validation is batched along with the action itself as an atomic action.
For example, an atomic action could be: check if the button is available, visible, clickable and only then click it — meaning less communication between node and the browser.

By doing the query and validation alongside the action, we prevent possible race conditions that could occur between waitFor -> client re-render -> action.

Some more benefits

Increased strictness: default locator will throw an exception if the selector matched more than one element.
More readable errors: depicts the exact issue of why an action cannot be done instead of a failing assertion or some generic timeout.

Final words

Battling flakiness isn’t a short-term thing.

It requires developers' awareness and care, writing tests more carefully, keeping in mind possible race conditions, and a conscience that tells them it isn’t okay to just rerun tests.

It requires assistive tooling for testing the test itself and monitoring it.

It requires priority, time, and guidelines — things you should receive from the technical management, thus requiring them to be aware of this issue.

A single developer cannot change the state of flakiness — a group effort is needed.

Flakiness is a manageable long-term battle. Empower yourself with the right tools to not only increase your development velocity, but also elevate your overall experience.

Sources:

Brief History of Frontend UI Tools and Newest Guy on the Block

Pavlo Lisovyi — Wed, 11 Jan 2023 18:31:55 +0000

My brief history with Front-end UI Tools

Front-end UI development is just writing code rendered in the browser, right? It can even be simplified a step further to say: 1. "Type code" and 2. "See the rendered output." That's it: Rinse, repeat as many times as needed, and you've got yourself the UI you're working on.

But humans are lazy — especially software engineers. Pair that with business people happy to pay for an increase in productivity, and you get a tools arms race.

Let's look back at some moments in the history of web UI development.

My UI development memories started in early 2008 when, during a "Web Development 101" course at university, a good friend taught me a trick. At the time, we were having issues with HTML/CSS styling and layouts. (Holy grail layouts were tricky back then, am I right?)

"Colorful markup," he called it. It wasn't then and isn't now a well-established term, so don't think you've missed something.

It works like this: When creating and tweaking layouts, use all possible colors for backgrounds, borders and outlines — pink, magenta, yellow, and red. I even use rebeccapurple sometimes. Feels like a good use for it.

Why? What were we doing back then, and why do some of us (slowly raises hand) still do it now?

Short answer: It's a helpful trick to speed up layout development. And, I'll admit, it's also a force of habit. It's hard to get rid of old habits and pick up new tricks (no, I'm not talking about the "using Vim plugins for VSCode" level).

As I was starting to work with Codux, which was new to me, I thought a lot about UI development — what I experienced and the history of the tools I encountered.

Behind the simple "type code" step, there are tons of different tools, most of which are shared with other software development areas not specific to web UI development.

In general, IDEs have made colossal progress in the last decades. Still, in my own experience, I started writing HTML tags like <IFRAME WIDTH=100> in Notepad (no pluses). Today, I have an IDE with tons of plugins and even an AI assistant. And we can't say this hasn't impacted front-end development. Of course, it has.

Case in point: I had a friend who was adamant back in 2012 that he had professionally developed HTML and CSS and would not need JS. At least, as long as it wasn't forced on him. Not more than a year later, he was using Grunt for simple templating (I think components weren't popular yet around that time).

CSS preprocessors needed CLI. Then, IDEs helped save some time in our dev cycle by auto-saving files. That was the first time my front-end development involved paid tools (Sublime, I'm looking at you).

File change watchers became the norm. Any UI development piece required at least CLI usage, if not modifying configuration files and so on. Most of the packages.json of front-end projects that I worked on around that time were pure "devDependencies."

Other tools were being developed closer to the "see the rendered output" side of the scale. And if you thought I was going to talk about Figma, you're damn right I am — but first, let's address the ancestor of all in-browser tools — development tools.

We recently said goodbye to a sweet prince who changed everything — Firebug. Firebug and Firebug Lite pioneered a format we've all been using for over a decade — and even if you've never used them yourself, screenshots from 2006 would immediately tell you that you're looking at "dev tools."

Of course, Chrome is the most significant player on the market nowadays. Its extensions system is enormous, with built-in dev tools functionality and custom tabs in dev tools. Most big framework players have their dev tools extensions already. But let's give credit to those who were there at the start. Firefox has been on the front lines of tools for web UI development since the beginning and up to today (from recent releases, I'm a fan of their flexbox inspector).

There are also code sandboxes. JSBin of 2012 is a great example. People needed a place to start developing, trying out ideas, and showcasing their code — but also be able to inspect it and play with it. As the complexity of front-end development grew, the complexity of sandboxes grew too, up to full-scale "Instant Dev Environments" like StackBlitz.

We can't avoid talking about other types of tools — let's call them design-oriented. Like Figma, I don't want to get too much into it, as it isn't a UI development tool. Nevertheless, it's been used as one by some, and it keeps me awake at night.

OK, so we've had a bit of nostalgia; maybe we smiled a bit about something, Googled something new, or just felt appreciative of the evolution of front-end development. But let's go back to the reason why I took you on that journey. Because of "colorful markup," remember?

Despite the evolution of dev tools, nothing has changed enough for me to drop it. Yes, CSS is now much more powerful and, one can say, stable and predictable. IDEs are tremendous and allow autocompletion, popups with documentation, and AI-proposed code.

But all of that was not enough to break my habit of needing to make an effort to keep my mind on the task of layout development. Switching the context between writing code and previewing output was always intact. Whatever was done outside, code always needed to be brought back manually — copied from tools and put somewhere. So if I were quick to type, with the help of the toolset behind me (Emmet, Live Templates, multiple cursors), that'd be quicker than any tool that would require me to integrate its "output" back to "my code."

Nothing, that is, until I started using Codux (also when building Codux, but that's a story for another day).

Because of what Codux does for me as a developer — it allows me to draft structure quickly, get classes on it, and start bashing together layouts — I see it with my own eyes on a preview (it is fully rendered production-grade stuff, with compiled preprocessed CSS, React components, etc.!). I can tweak nearly everything I can do via CSS on a style panel, and after all this — working on one screen with no navigation and no complex flow — I end up with proper HTML/CSS structure. When I think I'm done, I can commit, push, and start PR from Codux.

While learning React, I needed a simple sandbox environment — and I found it without leaving Codux. I just created a new board and started coding, with a preview of rendered output and all the tools mentioned above.

After an initial period of cautiousness, I'm embracing the next step in this evolution and dropping some old habits.

Move aside dev tools and sandboxes. It's time for visual editors to start building the future.

Attribution
Firebug screenshot - https://commons.wikimedia.org/wiki/File:Firebug.png#filelinks
JSBin v1 - https://www.flickr.com/photos/remysharp/4284906136

A visual is worth 1000 lines of code

Arnon Kehat — Mon, 12 Dec 2022 14:38:53 +0000

Why we believe in visual controllers

They say “a picture is worth a thousand words”. It's a saying that attempts to describe the difference between the amount of information that can be conveyed in a visual format, and the amount conveyed verbally or textually. In short, there’s no real contest. Visuals are faster and easier to use and understand than words for almost every person on the planet. This is the reason we build user interfaces in the first place—they help people interact with our systems in ways that would be difficult via text alone.
If you’re not convinced, try to compare the amount of time it takes you to absorb the information below, represented first as text, and then in a relatively agreed upon visual representation:

Bold: on || Italics: off || Underline: off || Text color: red || Text highlight color: yellow

The visual representation only requires a quick, almost instantaneous scan, while the text requires a few seconds of eyeballing even for the quickest reader (not to mention the additional screen space required).

When we want to design a new visual representation, we use the visual medium’s innate superiority to our advantage. And so, when we plan user interfaces, we use visual design tools (Figma, Sketch, Photoshop, etc.) They allow us to work with our eyes and hands to create the precise visual representation we want, all the while ignoring all other concerns (scale limitations, technical debt, performance, etc.). But their output is often completely static. It looks like our interface (often in its most basic forms), but it's miles away. To describe all its different interactions, we'd need to design it over and over again in all of its manifestations.

When we want to build the actual user interface, we are limited by current tools to using text that describes our visuals, their interactions and their logic (in our case text in the form of HTML, CSS and JS code). This happens because of technological limitations, because of old habits, and because developers take upon themselves an unfair share of the burden of making the systems work. They create the logic and infrastructure, as they should, but they also create the visuals and their interactions—because they are the only ones who can.

What we’re left with is thousands of lines of code that describe visual information, and a gap between stakeholders’ ability to directly affect the project. The textual description of the visuals is often completely opaque to the designer who designed them. Unless they are well-versed in reading and writing CSS and HTML (and many times other code flavors like React or Vue), they can point their finger at what’s wrong, but cannot fix it themselves.

This is where visual controllers come into play

Visual controllers are the set of tools that allow users to apply changes to code using their eyes and hands. For example, choosing a color via the mouse and a palette, or changing the size of a div by dragging its corners using the mouse.

They enable us to forgo the translation between visual and text, allowing us to use our senses to determine what should appear, and where. There are fewer “translation” layers, and therefore, less room for error as well as a quicker output. A designer’s eyes won’t miss a misplaced button visually. The same can’t be said for textual CSS comprehension, as good as we may be with CSS.

Visual controllers are also a great equalizer. They make design accessible and easy for people who may not know how to describe the same visuals in text format (practically anyone who has not spent years honing their front-end coding skills). They offer us a way to widen the circle of contributors, so that more of the stakeholders can directly affect the areas they own. (People who can’t make the translation from text to visual and back are often referred to as “non-technical”, but I think this is a boring and futile distinction.)

Let’s explore another example. We have some very basic HTML code of a modal that has an attribute data-open which determines whether it appears on screen or not. The HTML code looks something like this:

<div class="container"><div class="modal" data-open="true"><!--...modal content...--></div></div>

But, almost no developer in their right mind would work on it this way. Indentation and line breaks are the most basic visual manipulation developers use in order to show the DOM structure in a readable way. The output is often something like this:

<div class="container">
    <div class="modal" data-open="true">
        <!--...modal content...-->
    </div>
</div>

Now the structure is a lot easier to deduce thanks to a visual cue. With a visual controller we can go even further. We can show the conditional data-open in both of its possible states, open or closed, and use other visual aids to make this even easier to comprehend. The violet rail, for example, means a conditional DOM element in our current UI:

Note: The example above is not 1:1 as in the HTML example used previously. We use React in this example because that’s what our UI currently supports, but we think it still gets the point across.

The visual representation does something that the text cannot—it can reveal what other options are available. In the example above, we can see that there’s another option—the content we can display when our conditional is false. In this case and in many others, the visual controller helps us access the different options much easier than if we just had to keep them straight in our minds.

Conclusion

A good visual representation helps us form a better mental model. It can help with the understanding of hierarchies as they exist by making things that are dependent follow a visual ordering or flow. It can group together things that are related or that work together, making them easier to find and use, and improving their synergy. Most importantly, it can hint at what else is possible—what other options are available that may not jump out of the text.

We believe that visual controllers for structure and design can be helpful to anyone who participates in the interface creation process, and that this is a big part of what drives our development and design process. We believe in visual controllers.

Come see what we mean

Codux is a new visual IDE for React. It follows these principles, and combines the development and design processes into a single, faceted process. We are leveraging Codux in our everyday work to build Codux—visually editing the visual aspects of the application directly from within it. Download Codux and try it out to see for yourself how it improves the UI development experience. If you want to continue the discussion, leave a comment below or join our Discord server.

Introducing Codux

Nadav Abrahami — Mon, 05 Dec 2022 09:07:29 +0000

TL;DR - Introducing Codux, a new visual IDE for easing and accelerating the development of React projects. Learn more about it here, or join the conversation.

Hi, my name is Nadav Abrahami, and fifteen years ago I accidentally changed the web. I didn’t do it alone, and perhaps not all of it was unintended, but you may have heard of the result: the world’s first visual no-code website builder, Wix - the company that I co-founded.
Now, having been a developer for many years, I’m looking to change the web yet again. And again, not alone: with the help of a dedicated group and, most importantly, with you.

As Wix grew and advanced, utilizing new technologies, building a low code editor required a lot of, you guessed it, coding. Throughout the process, my feeling about web development grew to be quite similar to what I thought before creating Wix: it’s too messy, involving too many tools, too much repetitiveness, and too much effort. There has to be a better way of doing this!

And so we invented one.

“I Wish There Was a Button for That…”

As things stand now, the development process of a web application is a headache. Anyone who spent way too long switching contexts just to get a gradient right or struggling with a multilayered background knows exactly how time-consuming things can be. And many basic actions, like mocking complex data structures, wiring data to properties, or looking for the origin of a code definition, involve way too many steps. It’s repetitive and tedious. Whenever I encounter one of these cumbersome but necessary multi-step tasks, tasks which hold me from writing the real code, I find myself thinking: “I wish there was a button for that!”

In addition, as projects grow more complex, their code becomes more and more complex. Then I find myself switching between the IDE and the browser’s dev tools, just to find out what’s going on. This is especially true when considering the various states of internal components. Sometimes a clear view of the relevant part of the code I’m writing right now would save a lot of time and effort. I always wished there’d be a button for that.

When designers are involved, things can get even more frustrating, mainly because our means of communication are less than ideal: static designs and documents, or their own specialized tools. Whatever form the design spec is in, it’s not code. And so the developer must build the product, looks included, from scratch. The designer, meanwhile, has no way of being a part of the actual coding process, except for the occasional yell at the developer or a quiet sob in the corner. And so I find myself thinking: “Why not let them make the changes themselves? I wish there was a button for that!”

Unsurprisingly, it turned out I wasn’t the only one wishing. Far from it. And so my team started working on this wish list, and eventually created a new product. It’s the ultimate collection of buttons-for-that. It’s the place where all our wishes come true.

We call it Codux.

When You Wish Upon a Stack

Codux is a brand-new standalone tool from Wix designed to accelerate your development process, custom-made for developers and other related professionals. It’s a development environment that gives you a real-time visual rendering of your project, with numerous editing panels for quick modifications, and code editing where it’s relevant (or when you want to).

Download the MP4 video.

Codux analyzes your project to discover its UI components and general structure. It does so regardless of your code-writing style. When it makes changes - when you’ve changed a property, for example - it will write code the way you would write it. Codux is designed to be used alongside your favorite IDE. It works on React projects using TypeScript and when looking at the resulting code, you’d never know whether Codux was used or not.

The first thing you’ll notice when opening a project in Codux is the visual rendering stage. It shows how your components look in their various states. Every change you make will be reflected there in real time, whether it was done in Codux or elsewhere.

The stage also lets you quickly access the code related to any given component. By clicking on a component you can jump directly to its source, and quickly edit its content.

The second thing you’ll notice is the visual controls, the property, and the styling panels. Click on an element on stage, and the panels will reflect its properties. Changing styles, adding class names, and setting properties suddenly become easy and fast. No need to spend time looking for the relevant code. WYSIWYG galore!

The third thing is a visual representation of the render tree. It includes conditionals and data-bound repeaters. Keeping a mental model of your project - or someone else's project that you inherited - becomes much easier when you have a visual illustration to refer to. A map of the component.

It’s also fully Git-integrated, providing a collaborative environment for developers and designers alike. Just imagine how great it is when a designer doesn't need to send you a list of issues, but rather just fixes those on their own, using the exact same environment that you, the developer, do. The current back and forth between you two is reduced to having an occasional lunch together. Which is, to me, the best back-and-forth there is.
But this is only the first step on the road leading to a revolution in the way web development is done.

Now Wait a Minute…

Just in case, let’s quickly dispense with what Codux isn’t. It’s not a no-code/low-code editor (like the Wix editor). Nor is it a replacement for your IDE. Currently, like most developers, I use an IDE of my own choice set up just the way I like it. I won’t quickly replace it with something else, and I wouldn’t expect you to do that either.

Back to the Future

Eventually, Codux will become a one-stop shop for all stakeholders in a given project, covering everything from basic design to full deployment. It will support all frameworks - React, Vue, Svelte, Web Components, you name it - and all styling solutions. What we aim to make here is no less than the easiest, most comfortable, visual, and time-saving solution for writing web applications.

Yes, we know it’s a lot to do. But then, back when we originally created Wix, that seemed impossible as well. I think the results speak for themselves.

So What Now?

Right now, Codux can speed up your development process considerably. It works great with React, TypeScript, CSS, CSS/Sass Modules, and our very own Stylable. It’s also free of charge. So why not download it and give it a try? I’d love to hear your thoughts about it, either in a comment below or on our new Discord server.

In the eternal words of Doc Brown: “Roads? Where we’re going we don’t need roads.” Well, substitute “roads” for anything that holds back your development process right now - that’s where you and I are going.

Download Codux here.

DEV Community: Codux

React: Lessons from the Trenches - useEffect x Infinity

What to do?

What can be so complex?

1. Separate your gigantic useEffect into a few smaller ones

2. Debug the dependencies that are changing on every render

Conclusion

Experiments with the JavaScript Garbage Collector

Detecting Object Disposal

Example 1: Nested Objects

Example 2: Closures

Example 3: Eval

Example 4: DOM Elements

Example 5: Promises

In conclusion

The Future of CSS

Vanilla CSS

CSS-in-JS

Styled Components

Emotion

CSS-in-JS Advantages

CSS-in-JS Disadvantages

Side Note - Vanilla Extract

Component-Oriented CSS

CSS Modules

Avoiding Code Duplication

Stylable

Component Oriented CSS Advantages

Component-Oriented CSS Disadvantages

Utility First CSS

Utility-First CSS Advantages

Utility-First CSS Disadvantages

At the end of the day…

Flaky Tests, and How to Deal with Them

Intro

What is a flaky test?

How often does it fail?

1. Wasted CI minutes (Hours? Days? Weeks?)

2. Wasted development time

3. Flaky product behavior (or flaky implementation)

4. Alert fatigue

What's lost?

Causes of test flakiness

1. Poorly written test code

2. Poorly written application code

3. Infrastructural causes

4. Test tools that are prone to flakiness

Key takeaways up to this point

How to deal with flaky tests?

1. Collect data

2. Analyze it

Workflow reruns per day bar graph

Fail rate table

Fail by test scatter plot (Environmental factors)

3. Run new tests multiple times

Some more benefits that we got:

4. Set a bar for when a test isn’t flaky

Does your test only fail when running on CI?

Helping tests fail on your local machine

Find out what’s going on with a test on the CI

Stop using ElementHandles. Start using Playwright Locators

What's wrong with ElementHandles?

How Locators help us to get the correct DOM node

Some more benefits

Final words

Sources:

Brief History of Frontend UI Tools and Newest Guy on the Block

A visual is worth 1000 lines of code

Why we believe in visual controllers

This is where visual controllers come into play

Conclusion

Come see what we mean

Introducing Codux

“I Wish There Was a Button for That…”

When You Wish Upon a Stack

Now Wait a Minute…

Back to the Future

So What Now?

1. Separate your gigantic `useEffect` into a few smaller ones