DEV Community: Lucas ROURET

Streamline Your Code Reviews with SHIP SHOW ASK: A Modern Approach

Lucas ROURET — Sun, 11 Aug 2024 09:15:07 +0000

Pull Requests (PRs) are a crucial tool in the life of any tech project. They enable the introduction of new features and bug fixes, but they offer much more than that!

They foster discussion
Help identify business logic errors
Improve code quality
Facilitate knowledge sharing 🔥

In the tech world, practices have evolved significantly over the years. With faster development cycles and teams becoming more autonomous, it’s important to adapt our working methods.

➡️ One such adaptation involves rethinking how we manage code changes within the team.

Development teams are increasingly valuing autonomy. In this context, it’s crucial to strike a balance between rigor and flexibility in our processes. This is where the "SHIP SHOW ASK" method comes into play, aligning perfectly with this new dynamic.

But be aware, not all code changes are created equal. Some are critical and require immediate attention, while others are minor and can be handled with less formality. To address this variety, flexible approaches like "SHIP SHOW ASK" have emerged, allowing the review process to be tailored based on the nature of the change.

Introducing the SHIP SHOW ASK Method

"SHIP SHOW ASK" is a method that enables development teams to deliver code quickly while maintaining transparency and collaboration within the team. It consists of three key steps that adapt to different types of code changes: SHIP, SHOW, and ASK.

SHIP: for Quick Changes

When a developer identifies a change that doesn’t require a thorough code review—such as a minor fix or a documentation update—they can make this change directly on the main branch. The "SHIP" approach assumes that these changes are safe enough to be integrated without waiting for approval from other team members.

Why "SHIP" works well from a developer's perspective:

"I’ve added a feature using an established pattern."
"I’ve fixed a minor bug."
"I’ve updated the documentation."
"I’ve improved my code based on previous feedback."

SHOW: Merging with Confidence

In the "SHOW" stage, you work on a dedicated branch and open a PR. The key difference here is that you don’t need to wait for someone else to review your code before merging. You rely on automated checks (unit tests, code coverage, preview deployments, etc.) to ensure your code is ready. Once everything checks out, you merge and notify your team. They can then review what you’ve done, provide feedback, ask questions, or simply learn from your work.

Examples:

"Take a look at this new approach or model I’ve used."
"I’ve refactored X, here’s the outcome."
"I’ve fixed a bug; here’s how I did it."

ASK: Seeking Feedback and Collaboration

"ASK" comes into play when you’re uncertain about the approach you’ve taken or when you think feedback from your team could improve the quality of your code. You work on a dedicated branch, open a Pull Request, and wait for feedback before merging.

This approach is ideal for situations where:

You’re unsure if your solution is the best one.
You need help improving your code.
You’re working on a new feature or a major refactoring.

Understanding the Limitations of SHIP SHOW ASK

Here are some factors that limit the application of "SHIP SHOW ASK":

Lack of Continuous Deployment (CD) in the project.
Working with an unfamiliar or frequently changing team.
Lack of expertise within the team on the technologies used.
Lack of trust and discipline within the team.

These factors hinder the effectiveness of "SHIP SHOW ASK" by creating barriers to autonomy, responsiveness, and effective collaboration within the team.

Personal Insights on SHIP SHOW ASK

⚠️ This section reflects my PERSONAL opinion, providing you with my experience. It’s not advice—make your own judgment on "SHIP SHOW ASK" 😎

I genuinely believe that "SHIP SHOW ASK" is a great method, but there are prerequisites.

➡️ You need to trust your team and know them well. It might seem trivial, but knowing that your team members won’t SHIP a "while true" loop is crucial!

➡️ Know the project.

➡️ Know your strengths and weaknesses (strengths => SHOW, weaknesses => ASK). This will help you understand when to ask for help and how to learn from your team’s feedback.

Conclusion: Balancing Speed and Quality in Development

In conclusion, "SHIP SHOW ASK" is a versatile method that empowers development teams to balance speed and quality in their workflows. By categorizing changes into SHIP, SHOW, and ASK, teams can streamline their processes, foster collaboration, and maintain high standards of code quality. However, the success of this method hinges on trust, familiarity with the project, and a clear understanding of team dynamics. When these prerequisites are met, "SHIP SHOW ASK" can significantly enhance productivity and team cohesion, making it a valuable approach in modern software development.

Hi, I'm Lucas Rouret, a Web and Mobile Software Engineer passionate about technology since I was 15. I mainly work with JavaScript and TypeScript. Currently, I'm working on 2 startups
Interested in my content? Follow me on X (Twitter) and subscribe to my newsletter for weekly posts and detailed development logs. Join a community of tech enthusiasts now!

🔥 Check out my latest article "Boost Your React App's UX: Comprehensive Error Handling with Error Boundaries"

Source:

Boost Your React App's UX: Comprehensive Error Handling with Error Boundaries

Lucas ROURET — Wed, 07 Aug 2024 13:27:15 +0000

In this week's article, we will explore solutions for handling errors in React applications. Managing errors is crucial for delivering a quality user experience. Unhandled errors, like the absence of feedback when a button is pressed, can negatively impact user satisfaction. To enhance the user experience (UX), it is essential to avoid a lack of response or information when clicking a button or displaying a default 500 error. Today, we have several options for handling errors:

Using .catch on a promise for API calls.
Using the error option of React Query.
Using "Error Boundaries," which is what I will discuss this week.

To start, we will use a mock website and improve the code to achieve the best possible error management.

✏️ Creating a Mock Application: Setting the Stage for Error Handling

The application will fetch a list of users to display later.

Creating a User's hook

For the connector, we will use a non-existent domain name such as "fakeapiontheinternet.com" which will throw an error (we could have used a promise with a throw, but here I want to take a concrete example).

export const useUsers = () => {
  const { data } = useSuspenseQuery<Array<User>>({
    queryKey: ["users"],
    queryFn: () =>
      fetch("https://fakeapiontheinternet.com/users").then(
        (res) => res.json() as Promise<Array<User>>
      ),
  });

  return {
    users: data,
  };
};

We use React Query for the article. If you want to know more about useSuspenseQuery, read my article about Stop using useQuery from React-Query !

Structuring the Page: Building the Foundation

function App() {
  const { users } = useUsers();

  return (
    <div className="container">
      <div className="content">
        {users.length === 0 && <p>Empty ....</p>}
        {users.length !== 0 && users.map((u) => <p>{u.name}</p>)}
      </div>
    </div>
  );
}

Explanation of the Code Above

Using the previously defined hook:

const { users } = useUsers();

Displaying users based on the state value: "Empty ..." if there are no users, or the usernames of the users.

 {users.length === 0 && <p>Empty ....</p>}
 {users.length !== 0 && users.map((u) => <p>{u.name}</p>)}

👀 Code Decryption: understanding and anticipating Errors

There is a concept I really like in development: "First Run First Win." The principle is very simple. It's like a little game against yourself that leads to significant reflection and learning. For example, in our case, you coded with me, but you don't know the result. Try to play the game and guess the result of this:

What happens when I load the page?

Have you played the game? 🎰

The answer: Nothing happens!

Not exactly nothing!

If we analyze our code, our 'useUsers' hook has generated an error, which has halted the execution of the rest of the code. That's why we don't even see the "Empty ...".

Put yourself in the user's shoes; this situation is so frustrating!

🛡️ Error Boundaries: React's Built-in Solution for Error Handling

Error boundary is a feature in React. To quote:

By default, if your application throws an error during rendering, React will remove its UI from the screen. To prevent this, you can wrap a part of your UI into an error boundary. An error boundary is a special component that lets you display some fallback UI instead of the part that crashed—for example, an error message.

This exactly addresses our problem!

To handle our error, we will:

Create the "UserList" component which will call our hook.
In <App />, we will wrap <UserList /> with <ErrorBoundary />.

Personally, I work with React and React Native. The 'react-error-boundary' library is perfect because it ensures compatibility with both React and React Native.

The ErrorBoundary component has several properties:

fallback: The simplest way to render a default "something went wrong" type of error message.
fallbackRender: A function responsible for returning a fallback UI based on the thrown error.
FallbackComponent: A React component responsible for returning a fallback UI based on the thrown error.
onError: For logging.

Implementing Error Boundaries: Step-by-Step Guide

Let's create the UserList component, containing our previous code for displaying users.

const UserList = (): JSX.Element => {
  const { users } = useUsers();

  return (
    <div className="content">
      {users.length === 0 && <p>Empty ....</p>}
      {users.length !== 0 && users.map((u) => <p>{u.name}</p>)}
    </div>
  );
};

Let's update the content of our App to call the UserList component.

function App() {
  return (
    <div className="container">
      <UserList />
    </div>
  );
}

Integrating Error Boundaries: Enhancing User Experience

<ErrorBoundary fallback={<div>Something went wrong</div>}>
     <UserList />
  </ErrorBoundary>

We use ErrorBoundary from the "react-error-boundary" library to catch and handle errors in our UserListcomponent. The fallback prop is used to render a simple error message ("Something went wrong") when an error occurs. This ensures that the entire UI does not crash and provides a better user experience by displaying a meaningful message instead of a blank screen or a default error page.

Now, we have an error message ✨

We can now define our ErrorView and change the fallback property to FallbackComponent.

const ErrorView = ({ error, resetErrorBoundary }: FallbackProps) => {
  return (
    <div>
      <h1>Something went wrong</h1>
      <p style={{ color: "red" }}>{error.message}</p>
      <button onClick={resetErrorBoundary}>Try again</button>
    </div>
  );
};

function App() {
  return (
    ...
      <ErrorBoundary FallbackComponent={ErrorView}> <---
        <UserList />
      </ErrorBoundary>
    ...
  );
}

💡 The code for my articles is available on this REPO

🔥 Conclusion: Mastering Error Handling for a Seamless User Experience

Mastering error handling in React is crucial for providing a seamless user experience. Techniques like using .catch on promises, leveraging the error option in React Query, and utilizing Error Boundaries ensure that your application remains robust and user-friendly even when unexpected errors occur. Error Boundaries, in particular, provide a powerful way to catch and handle errors gracefully, preventing your entire UI from crashing and allowing you to display meaningful fallback content. This not only improves the user experience but also makes your code more maintainable and elegant. By adopting these practices, you can create more resilient React applications that keep users engaged and satisfied.

In conclusion, transitioning to useSuspenseQuery and ErrorBoundary from traditional isLoading and error handling methods offers a more elegant and maintainable approach. It enhances both the developer experience and the end-user experience by ensuring that errors are managed gracefully and the application remains robust. By mastering these error handling techniques, you can build React applications that are not only resilient but also provide a seamless and satisfying user experience.

Hi, I'm Lucas Rouret, a Web and Mobile Software Engineer passionate about technology since I was 15. I mainly work with JavaScript and TypeScript. Currently, I'm developing a browser-based hero management game similar to "Raid Shadow Legends."

Interested in my content? Follow me on X (Twitter) and subscribe to my newsletter for weekly posts and detailed development logs. Join a community of tech enthusiasts now!

Stop using useQuery from React-Query !

Lucas ROURET — Sun, 04 Aug 2024 16:04:25 +0000

In any web application, managing loading and error states is crucial. Displaying loading states keeps the user informed, but historically, this management can be tedious to implement manually.

React Query greatly simplifies the handling of loading states and global states. Indeed, React Query avoids redundant requests, thereby optimizing the application's performance.

Let's take a code example that implements a loading state in our application.

Define a hook to fetch a list of users:

export const useUsers = () => {
  const { data, isLoading } = useQuery<User[]>({
    queryKey: ["users"],
    queryFn: async () => {
      const response = await fetch("https://jsonplaceholder.typicode.com/users");
      await new Promise((resolve) => setTimeout(resolve, 2000));
      return response.json();
    },
  });

  return {
    users: data?.slice(0, 4) || [],
    isLoading,
  };
};

Here, we fetch four users with useQuery. We add a 2-second delay to illustrate the loading state. We then return the data and a boolean for the loading state.

On the component side, let's create a component named Example:

const Example = (): JSX.Element => {
  const { users, isLoading } = useUsers();

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return (
    <div className="container">
      <div className="user-action">
        <h1>Users</h1>
        <div>
          <button>Add users</button>
        </div>
      </div>
      <UsersList users={users} />
    </div>
  );
};

In this component, we use our hook to fetch the list of users. Before rendering the view, we perform an "early return" with a loading message, then display the title, button, and users.

Limitations and Alternatives

However, each network call requires explicit management of the loading state. If the code is not factorized, some elements of the view might be waiting to be displayed, such as the title and action.

Here is an alternative to avoid blocking the view:

import "./App.css";
import UsersList from "./UsersList";
import { useUsers } from "./useUsers";

const Example = (): JSX.Element => {
  const { users, isLoading } = useUsers();

  return (
    <div className="container">
      <div className="user-action">
        <h1>Users</h1>
        <div>
          <button>Add users</button>
        </div>
      </div>
      {isLoading ? <div>Loading...</div> : <UsersList users={users} />}
    </div>
  );
};

Here, we use conditional rendering instead of an "early return". This solution is less readable and harder to maintain in complex components.

The Ideal Solution: A Generic Loading Component

The most ingenious solution is to create a component that renders our loading message or our main component based on a variable.

type Props = PropsWithChildren<{
  isLoading: boolean;
}>;

const LoadingWrapper = ({ children, isLoading }: Props): JSX.Element => {
  if (isLoading) {
    return <div>Loading...</div>;
  }

  return <>{children}</>;
};

Usage in Our Component

const Example = (): JSX.Element => {
  const { users, isLoading } = useUsers();

  return (
    <div className="container">
      ...
      <LoadingWrapper isLoading={isLoading}>
        <UsersList users={users} />
      </LoadingWrapper>
    </div>
  );
};

This factorization centralizes the conditional rendering logic and unifies the use of loading messages, offering cleaner and more maintainable code.

Discover the Magic of Suspense

But now, if I tell you that this component we just created is already built into React. Even better, it's magical! No more manual management of isLoading states!

How?

With React's Suspense (React version >= 16.6), everything becomes simpler and cleaner. Suspense allows you to explicitly declare to React that a component is waiting for asynchronous data, and React takes care of managing everything for us.

Implementing useSuspenseQuery

Let's use useSuspenseQuery to automatically manage the loading state. Here's how to do it:

Hook to Fetch Users

export const useUsersSuspense = () => {
  const { data } = useSuspenseQuery<User[]>(
    ...
  );

  return {
    users: data?.slice(0, 4) || [],
    // Without the isLoading
  };
};

Usage in the Component with Suspense

Now, let's update our Example component to use Suspense:

const UsersComponent = (): JSX.Element => {
  const { users } = useUsersSuspense();

  return <UsersList users={users} />;
};

const Example = (): JSX.Element => {
  return (
    <div className="container">
      <div className="user-action">
        <h1>Users</h1>
        <div>
          <button>Add users</button>
        </div>
      </div>
      <Suspense fallback={<div>Loading...</div>}>
        <UsersComponent />
      </Suspense>
    </div>
  );
};

Advantages of Suspense

With Suspense, we centralize the management of the loading state in one place, making the code more readable and maintainable. The Suspense fallback automatically displays as long as the data is not available, eliminating the need to manually manage isLoading states.

Moreover, Suspense encourages development teams to factorize their code. By using standardized loading components and asynchronous state handlers, developers can create reusable and consistent modules, thus improving code quality and maintainability in the long term.

Conclusion

Using Suspense and useSuspenseQuery revolutionizes the management of loading states in React applications. This approach not only simplifies the code but also enhances the user experience by ensuring smooth and consistent rendering. Transitioning from useQuery to useSuspenseQuery is a natural evolution for cleaner and more efficient applications.

Additionally, integrating Suspense encourages development teams to factorize their code. In conclusion, adopting Suspense and useSuspenseQuery is not just a technical improvement, but also a step towards healthier and more effective development practices.

My Newsletter :D