DEV Community: Anurika Joy

Say Goodbye to Flaky Rendering & Animation Issues

Anurika Joy — Mon, 27 May 2024 00:30:01 +0000

Introduction

User interface rendering and animations provide an application with an awesome and interactive user sensation. As amazing as this idea sounds, so is how vexing it can get when things go sideways. And one way wherein that circumstance could materialize is through trials that fluctuate.
How To Repair Flaky Trials in Rendering & Animation Maneuvers

There are definitely numerous motives behind flaky trials in rendering or cartoons; nevertheless, one of the prime reasons is timing.

For illustration, you might own a spring cartoon of a fastener showing. At present, trialing this might lead to flakiness, all due to the animation getting completed some nanoseconds too tardy as a result of a random backdrop managing process.

In this handbook, we’ll be utilizing Jest and React trialing libraries to portray real-world cases of trials for better comprehension. Nonetheless, you can tag along, regardless of your stack.

Ground Origins

Flaky trials, in general, encompass rather a few communal causes. However, when getting precise about UI rendering and animations, here are the principal ground origins:

Timing Predicaments

Animations by default often arrive with setTimeout delays or transition-duration attributes. These timings are at times what result in assertions flunking, leading to flakiness.

Take a glance at this trial for a component with an animation where its breadth gets enlarged with the tap of a fastener:

test("Box breadth increments", () => {
render();
const box = screen.getByTestId("box");
assume(box).toHaveStyle({ width: "70px" });

fireEvent.click(screen.getByRole("button"));
assume(box).toHaveStyle({ width: "100px" });
});

The catch right here is that after tapping the key to escalate the breadth, the assertion might execute before the animation of the dimension increment wraps up, subject to any timing occurrences.

Consequently, the prime predicament in rendering and animation trialing descends to guaranteeing that assertions are made after the animation has fully executed and not earlier. A nice tactic would be to wait for the animation to complete; in React trialing, this can be accomplished utilizing the use of waitFor.

Environmental Dependencies

The system resources come into play in this instance. In a form, trials devised for rendering intricate animations can be contingent on system resources like CPU or memory.

At present, this won’t be an issue for machines that are adept. Nonetheless, if the machine has restricted resources, animation rendering could stumble and be less velvety, thereby initiating random trial failings.

Another illustration of environmental dependencies can be network connectivity. Presume you own an animation that hinges on retrieving external assets; this solo introduces sporadic factors as network oscillations can sway the animation behavior. A technique to mend this would be with the use of mocks.

Libraries Dependencies

Oftentimes, animations employed are from libraries, as it is much quicker and more effective than authoring the code from scratch.

In React for instance, there are stacks of animation libraries like Framer Motion, React Spring, etc. Nevertheless, these libraries could prompt flaky trials when:

the version of the third-party library and the ongoing version of the technology stack employed are not harmonious. This case is sometimes tacit, as blunders might not be exhibited, just that the tests outcomes appear to wobble.
- the animation libraries employed own dependencies that intercede with one another.
the animation libraries contain interior bugs that haven’t been patched by the library developers which only materialize during trialing.
- developers use animation libraries in a technique it wasn’t purposed for. Remarkably enough, the library might accomplish the duty as anticipated but since it was employed inaccurately, trialing can furnish unpredictable outcomes. ##Rectifying Flaky Trials in Rendering & Animation At present, to make this handbook more intricate and easier to grasp, we’ll present four real-world code cases and depict the incorrect way precipitating flaky trials and the correct way to remedy them.

Rendering of a Newsletter Prompt

In this instance, this component renders a simple form with an email input and a subscribe button. When submitted, it logs the email and resets the state.

function NewsletterPrompt() {
const [email, setEmail] = useState("");
const [subscribed, setSubscribed] = useState(false);

const handleSubmit = (e) => {
e.preventDefault();
setSubscribed(true);
};

return (
{!subscribed ? (

<h2>Subscribe to Bulletin</h2> setEmail(e.target.value)} /> Subscribe ) : (
Subscribed effectively
 )}
 ); }

At present let’s script a trial for the component that’ll show how flakiness can transpire:

test("Bulletin southern renders and can be subscribed to", () => {
render();
const emailInput = screen.getByPlaceholderText("Email address...");
const subscribeButton = screen.getByText("Subscribe");

fireEvent.change(emailInput, { target: { value: "xyz@example.com" } });
fireEvent.click(subscribeButton);

assume(screen.getByText("Subscribed effectively")).toBeInTheDocument();
});

The predicament right here is that making assertions directly like this could run before the component even re-renders to show updates of the submitted email.

This trial is bound to be flaky because it relies on the component being rendered synchronously, which might not always be the case. As rendering can sometimes be asynchronous.

A mend for this trial would be something like this:

test("Bulletin southern renders and can be subscribed to", async () => {
render();
const emailInput = screen.getByPlaceholderText("Email address...");
const subscribeButton = screen.getByText("Subscribe");

fireEvent.change(emailInput, { target: { value: "xyz@example.com" } });
fireEvent.click(subscribeButton);

assume(
await screen.findByText("Subscribed effectively"),
).toBeInTheDocument();
});

In this mend, we employed async/await and the screen.findByTexttechnique to anticipate and wait for the text content element to show up in the DOM, which would confirm that the component has forsooth re-rendered with the “Subscribed effectively” notification.

An Animated Key

Let’s presume you own a fastener that animates its color from orange to blue when clicked and reverts to orange when clicked again.

export nonremovable function AnimatedButton() {
const [isAnimated, setIsAnimated] = useState(false);

const handleClick = () => {
setIsAnimated(!isAnimated);
};

const buttonStyle = {
dimension: "100px",
height: "50px",
backdropColor: isAnimated ? "blue" : "orange",
transition: "backdropColor 0.5s ease",
};

return (

Analyze

);
}

Now here’s a frequent but incorrect way to script the trial for this button color change, as it could evince flaky actions:

import { render, fireEvent } from "@testing-library/react";
import AnimatedButton from "./AnimatedButton";

test("background color changes", () => {
render();
const button = screen.getByRole("button", { name: "Animate" });

fireEvent.click(button);
assume(button).toHaveStyle({ backdropColor: "blue" });

fireEvent.click(button);
assume(button).toHaveStyle({ backdropColor: "orange" });
});

This trial appears truly straightforward; it renders the button, clicks it, and then asserts the awaited color changes. However, there’s a tad of a lax spot, which is where flakiness steps in.

The reason this trial might at times evince flaky outcomes is that after each click event, it assumes that the animation finishes immediately, as we aren’t assessing the timing of the animation before asserting the status of the button’s background color.

As an alternative, this would be the right way:

test("background color changes", async () => {
render();
const button = screen.getByRole("button", { name: "Animate" });

fireEvent.click(button);
await waitFor(() => assume(button).toHaveStyle({ backdropColor: "blue" }));

fireEvent.click(button);
await waitFor(() =>
assume(button).toHaveStyle({ backdropColor: "orange" }),
);
});

With this mere change of utilizing waitFor, we can be certain that the trial would permit the animation to be finalized before asserting the backdrop color of the button. This ensures that the trial assertion is in sync with the UI’s rendering update.

Rendering of a Basic Panorama
For this exemplar, let’s utilize a simple panorama component that when a fastener is clicked, the visibility of the panorama alters:

function AnimatedWindow() {
const [isApparent, setIsApparent] = useState(false);
const toggleVisibility = () => setIsApparent(!isApparent);

return (
Toggle Panorama {isApparent && Animated Panorama}
 ); }

Now as plain as this component is, trialing if it renders rightfully can grow into a hitch due to the animation.
Here is an incorrect way to script the trial:

test("Toggling animated panorama", () => {
render();
const toggleButton = screen.getByRole("button", { name: "Toggle Panorama" });

assume(screen.queryByTestId("animated-modal")).not.toBeInTheDocument();
fireEvent.click(toggleButton);
assume(screen.getByTestId("animated-modal")).toBeInTheDocument();
});

As we portrayed in the foregoing exemplar, this trial also asserts the presence of the panorama content straight away after the click event. Thus, due to the animations being asynchronous, this trial is bound to be a flaky one.

Here’s the right way:

test("Toggling animated panorama", async () => {
render();
const toggleButton = screen.getByRole("button", { name: "Toggle Panorama" });
assume(screen.queryByTestId("animated-modal")).not.toBeInTheDocument();

fireEvent.click(toggleButton);
await waitFor(() => {
assume(screen.queryByTestId("animated-modal")).toBeVisible();
});

fireEvent.click(toggleButton);
await waitFor(() => {
assume(screen.queryByTestId("animated-modal")).not.toBeInTheDocument();
});
});

In this mend, we employed waitFor to assert the panorama’s presence or absence visibility only after the animation has been finalized. This gives us the assurance that the trial is more dependable.

actics to Minimize Flaky Trials in Rendering & Animation

So when scripting trials expressly for UI rendering and animations, here are some facets to look out for or what you should exploit rather to lessen the likelihood of flaky trials showing up:

Always scrutinize the trial logic scripted as it is one of the communal mistakes made as elucidated in the section above.
Network lags or fluctuations should be taken into account, and mock functions can be handy in fixing this.
When trialing on UI rendering, bypass utilizing DOM selectors like .querySelector() to fetch elements, rather employ the queries dispensed by the trialing library like getBy, queryBy, or findBy.
Assure that the version of the animation library employed is harmonious with the version of the tech stack employed.
Retain the rendering or animation trials in smaller units i.e. endeavor to only trial one component at a time. This is more capable and simpler to debug flakiness.
Comprehend when to utilize the apt assertion matchers, for instance when trialing animations, toBeVisible() is superior suited than toBeInTheDocument().
Utilize waitFor for assertions and not for firing events.
You can utilize jest.useFakeTimers() as an alternative to waitFor for further control of trialing.
Some developers drop/disable animations when trialing, while it’s not advocated, it is an option.

Conclusion

Flaky trials in rendering and animations can genuinely be intricate to manage with; but with a proper understanding of the communal causes exclusively timing complications, the flakiness of trials can be curtailed tremendously.

Explaining the Concept of the State Pattern in Flutter

Anurika Joy — Sun, 26 May 2024 22:36:41 +0000

The State Pattern serves as a behavioral design pattern that helps in encapsulating various behaviors for an object according to its internal state. This allows an object to modify its behavior dynamically without relying on conditional statements, ultimately enhancing maintainability.

Unpacking the Essence of the State Pattern

As per the Design Patterns in Dart resource, the State Pattern acts as a behavioral design pattern pivotal in encapsulating diverse behaviors for an object based on its internal state. With this approach, an object can adjust its behavior dynamically without the need for conditional statements, thereby simplifying the codebase.

Essentially, each state of an object gets represented by distinct classes, serving as extensions or variations of a core state class specific to that object.

Diving Deeper into the Concept

Consider having an object like Water, where you define a WaterState to embody variations such as Solid, Liquid, and Gaseous:



abstract class WaterState {
  //
}

class Solid extends WaterState {
  //
}

class Liquid extends WaterState {
  //
}

class Gaseous extends WaterState {
  //
}

Furthermore, the State Pattern becomes a vital component of the BLoC pattern. If you are employing the BLoC pattern, you are essentially leveraging the State Pattern.

Ideal Scenarios for Implementing the State Pattern

The State Pattern comes in handy under the following circumstances:

When an object behaves differently based on its state.
If the number of states is substantial, and state changes are frequent.
When a class features a multitude of conditionals affecting its behavior related to field values.
In cases where there is significant code duplication for similar states and transitions.

Application of the State Pattern in Real Life

Let's now explore a practical example showcasing the State Pattern in action. Consider the class below, where state definitions incorporate variables and ChangeNotifier:



class CategoryStore extends ChangeNotifier {
  List<String> categories = [];
  bool isLoading = false;
  String error = '';
  IApiDatasource apiDatasource = ApiDatasource();

  void getCategories() async {
    isLoading = true;
    await apiDatasource.getCategories().then((response) {
      response.fold(
        (left) => error = left.message,
        (right) => categories = right,
      );
    });
    isLoading = false;
    notifyListeners();
  }
}

The fold() method highlighted above is associated with the Either type, an essential element in functional programming that represents a value falling under one of two specified types. Typically, Either represents a successful or failed value, much like in the example where left signifies the error value and right signifies the success value.

Within the aforementioned class, a function initiates loading through isLoading, then proceeds to fetch data from an API, storing it in the categories variable. Upon completion of loading, the function adjusts the value to false.

To streamline this code using the State Pattern, we structure it as follows:

Defining State Classes

The states and their corresponding classes are declared initially:



abstract class CategoryState {}

class CategoryInitial extends CategoryState {}

class CategoryLoading extends CategoryState {}

class CategoryLoaded extends CategoryState {
  final List<String> categories;
  CategoryLoaded(this.categories);
}

class CategoryError extends CategoryState {
  final String message;
  CategoryError(this.message);
}

Refining the Store Class

In the getCategories() function, we eliminate the isLoading variable and introduce the value variable, representing the state within ValueNotifier and adhering to the CategoryState. Consequently, CategoryLoading is designated to signify our state.

Subsequently, in the fold() method, if the request flounders, value transitions into the Error state carrying the error message (left). Conversely, upon a successful outcome, it adopts the Loaded state with the data residing in the right variable. This workflow discards the categories and error variables:



class CategoryStore extends ValueNotifier<CategoryState> {
  CategoryStore() : super(CategoryInitial());

  IApiDatasource apiDatasource = ApiDatasource();

  void getCategories() async {
    value = CategoryLoading();
    await apiDatasource.getCategories().then((response) {
      response.fold(
        (left) => value = CategoryError(left.message),
        (right) => value = CategoryLoaded(right),
      );
    });
  }
}

The value getter pertains to ValueNotifier, housing the present state of our Store class.

Demonstrating an Instance within a Page



class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  // CategoryStore instance establishment
  CategoryStore store = CategoryStore();

  // Initialization function upon page load
  @override
  void initState() {
    store.getCategories();
    super.initState();
  }

  @override
  void dispose() {
    super.dispose();
    store.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Expanded(
        // Observing the store
        child: ValueListenableBuilder(
          valueListenable: store,
          builder: (context, value, child) {
            // Error handling
            if (value is CategoryError) {
              return Center(
                child: Text(
                  'Error loading categories: ${value.message}',
                ),
              );
            }
            // Presenting loaded data
            if (value is CategoryLoaded) {
              return ListView.builder(
                itemCount: value.categories.length,
                itemBuilder: (context, index) {
                  final category = value.categories[index];
                  return Text(category);
                },
              );
            }
            // Display loading status
            return const Center(child: CircularProgressIndicator());
          },
        ),
      ),
    );
  }
}

In this manner, we have successfully implemented the State Pattern! Through this approach, we adhere to the Single Responsibility and Open/Closed Principles, and streamline the code by eliminating conditional statements that could otherwise complicate the codebase.

Wrapping Up

Your journey through this exploration of the State Pattern is greatly appreciated. While the focus was on the State Pattern itself, I refrained from delving too deeply into elements like ValueNotifier and others utilized in the example.