Forem: Wecasa

Letting the ducks fly: How we’re switching from Redux to React Query

Mathieu Tinoco — Thu, 06 Nov 2025 18:54:26 +0000

An incremental journey from Redux modules to intuitive async data management

Years ago we adopted Redux to manage the client state, handle the local state, and control data fetching. More recently, we began transitioning to React Query. Redux is primarily designed as a synchronous state manager, while React Query specializes in managing the asynchronous state.

Both are agnostic to the underlying fetching library, but Redux requires significant boilerplate to handle async operations, whereas React Query offers built-in patterns that make data fetching, caching, and updating feel more natural. We decided these advantages made React Query a better fit for our codebase.

Depending on the size of the application, migrating to React Query can require a significant amount of time. In our case, rather than setting a strict deadline, we are treating the migration as an ongoing effort over a year or so as we gradually replace the asynchronous Redux logic with React Query in the flow of continuous integration.

1. A compelling library

In Redux, managing server data involves manually updating state through actions and reducers, which can be cumbersome and repetitive, especially when dealing with asynchronous API calls. Because Redux is a synchronous state library, handling asynchronous behavior requires middleware like redux-thunk, adding even more boilerplate to the process.

State synchronization and caching are hard problems in their own right, especially when they involve keeping frontend and backend data in sync. React Query simplifies this process by automatically caching server data and offering built-in tools for refreshing and invalidating queries.

Instead of handling complex state updates, React Query’s staleTime and gcTime settings handle caching and data refreshing automatically; queries are invalidated when data might be outdated, and refreshed only when necessary. This lets React Query act as a specialized cache for server-state, which frees us from having to manually synchronize state with the API and allows us to keep our API as the single source of truth.

Therefore, we avoid manual data updates and instead use React Query’s default caching setup to stay synchronized with the server. For most queries, we use:

staleTime: Set to 0ms (default), so that data is always considered stale and automatically refetched on each rerender, along with other situations. Some are controlled by configuration, others handled by default. (We sometimes make an exception here - see further down)
gcTime (formerly cacheTime in V4): Set to 5 minutes (default). gcTime stands for garbage collection time. It is a countdown that starts once the query becomes inactive (e.g., when the component unmounts or the app goes to the background), after which the data is removed from memory. cacheTime was a misleading name for a countdown, which is why, in React Query v5, it was renamed gcTime to better reflect its role.

This approach lets us keep our code light. Rather than tracking and updating cache manually as in Redux, we simply invalidate queries when needed, and React Query handles refetching and cache expiration for us.

For example, after successfully uploading a document with putDocuments, we invalidate the ['documents'] query and React Query refreshes the document list automatically.

import { useQuery, useMutation, useQueryClient } from '@tanstack/react-query'
import { getDocuments, putDocuments } from './api'

const useDocuments = () => {
  return useQuery({ queryKey: ['documents'], queryFn: getDocuments })
}

const useUploadDocument = () => {
  const queryClient = useQueryClient()
  return useMutation({
    mutationFn: putDocuments,
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['documents'] })
    },
  })
}

const Documents = () => {
  const { data: documents } = useDocuments()
  const { mutate: uploadDocument } = useUploadDocument()

  return (
    <>
      <ul>
        {documents?.map(doc => (
          <li key={doc.id}>{doc.name}</li>
        ))}
      </ul>
      <button onClick={() => uploadDocument({ name: 'New Document' })}>
        Upload Document
      </button>
    </>
  )
}

2. Rethinking loading / error logic

React Query makes working with asynchronous data feel seamless. Because data fetching, caching, and synchronization are built into its core, handling loading or error states becomes part of the natural flow.

We choose between 3 main solutions to deal with a loading state:

Let the component render (with no data) and re-render naturally when data is available. If the data being fetched is low priority and has little impact on the main content, we tend to just let the component render. The missing data will appear on the page once the content has been successfully received.

const useGetDocumentsQuery = () => {
  const {
    data: documents,
    isLoading: isLaodingDocuments,
    isError: isDocumentsError
  } = useQuery<Document[], Error>({
    queryKey: DOCUMENTS_QUERY_KEY,
    queryFn: async () => {
      const response = await get("/pro/documents");
      return response.data;
    },
  });

  return { documents, isLaodingDocuments, isDocumentsError };
};

const DocumentPage = () => {
  const { documents } = useGetDocumentsQuery();

  return (
    <>
      <title>Documents</title>
      {documents && <p>You have {documents.length} documents</p>}
    </>
  );
};

Return null as long as the data isn’t ready (your screen will remain blank in the meantime). In most cases, when loading time is less than 300ms, we choose to return null while data is fetching and let the page render once the component has everything it needs.

const HomePage = () => {
  const { documents, isLoadingDocuments, isDocumentsError } = useGetDocumentsQuery();
  if (isLoadingDocuments) return null;
  if (isDocumentsError)
    return <p>Error handling here.</p>;

  return <>HomePage content</>;
};

Display a loader (spinner, skeleton, progress bar, etc.). If the page relies heavily on the data and fetching takes time, we like to let the user know that something is cooking up! A loader is quick to implement and a shimmer effect often makes the experience feel smoother.

const HomePage = () => {
  const { documents } = useGetDocumentsQuery();
  if (!documents) return <LoaderComponent />;

  return (
    <>
      <ChildComponent documents={documents}/>
    </>
  );
};

Side note: in the example above, we check !documents instead of isLoadingDocuments so that documents can't be undefined in ChildComponent. This ensures that by the time ChildComponent is rendered, documents is always defined. In TypeScript, this narrows the type so we don’t have to handle documents being undefined inside ChildComponent.

3. How we got started

In our codebase, we usually have one duck per API resource. In Redux, a duck is simply a module that organizes everything related to one feature (its action types, action creators, and reducer) into a single file. Most of our ducks are independent and can be migrated one by one, allowing PRs to be kept small and comprehensible.

After identifying which duck to migrate, we review the API calls handled by its action functions. For each API resource, we create a dedicated custom hook to handle that request. These custom hooks encapsulate the React Query logic and manage the state related to that request. We consider this a good practice since it avoids duplicating request-related code and provides a clear, reusable interface for consuming components.
Next, we focus on the highest-level component in the stack that consumes the data, since this is usually where most of the work is required. Instead of deleting the existing Redux code right away, we often comment it out. This makes it easier to refer back to during the migration, as parts of the logic can still be reused.
From there, the process is pretty straightforward: we plan for what should happen while the data is loading, once it's available, and if an error occurs. React Query provides a rich set of status flags that let us adapt our component’s logic.

4. Challenges & corner cases

We have encountered a few bumps along the road to implementing React Query...

Testing
Testing our components was the first roadblock that we hit. We believe in integration testing and wanted to keep it up with the components that now use React Query.

We ended up using msw (mock service worker) which is a middleware that intercepts real API calls and returns a mocked response. Our configuration lets us mock all API endpoints at once in a dedicated file, so that we don’t need to mock for each individual test case. For specific test cases, we can still override individual responses directly within the test.

Compared to Redux, where we mocked the API layer extensively, this approach feels closer to real-world behavior and it gave us greater confidence in how our components interact with the API.

gcTime
We also encountered challenges in specific cases with staleTime and gcTime due to the default staleTime being set to 0, which sometimes triggered redundant API calls. This can occur when multiple components using the same query mount nearly simultaneously but with a slight delay of just a few milliseconds. React Query treats the data as stale for each mount, causing multiple requests. Setting a short staleTime of 1 second was enough to prevent this.

Some dispatch functions can overlap between ducks.
In a few cases, ducks in our codebase call dispatch functions from another ducks. Normally, ducks handle a single API resource, but we occasionally violated this rule, creating cross-duck side effects. During migration, we move such logic into a temporary regular function so the other duck can keep working; it can be removed once the second duck is migrated.

In these cases, if the temporary function mutates data, make sure to invalidate the React Query cache for any affected API resources.

Conclusion

Switching from Redux to React Query has greatly simplified the way we manage server state. Redux works well for the synchronous state, but asynchronous workflows require middleware like redux-thunk and extra boilerplate. React Query was built for that purpose, with caching, query invalidation, and automatic refetching, making it easier to keep the API as the single source of truth while improving maintainability.

I hope this article inspires you to explore React Query or refine your own migration strategies. Let us know your thoughts, challenges, or tips in the comments!

How to schedule an update of a React component in the future

Antoine Quinquenel — Thu, 30 Jan 2025 09:35:50 +0000

`useRerenderTimeout` & `useRerenderInterval` : 2 custom hooks to re-render a React component at a specific time, or at a regular interval of time.

⚡️ In a hurry ? Go directly to the TL;DR section.

Most of the time, we develop user interfaces (UI) that react to user interactions.
But what if you need the UI to react to the current time ?

At Wecasa, we recently needed some content of our React Native app to update automatically at a specific time.
To do so, we created two custom hooks that allow a component to re-render itself at a specific time or at a regular interval of time, with a simple and generic implementation for a great developer experience. ✨

Trigger a re-render at a specific time

Let's say we want to create a Meeting component that renders differently depending on whether the meeting has started or not.

Currently, nothing forces the component to change once the meeting starts. This means, if it is displayed at 13:59 and the meeting starts at 14:00, after one minute it will continue showing the meeting as upcoming even though it has started.

To force a re-render of the component, we can simply trigger a state update with a local timer that executes at the meeting's start time.

The timer is set via a custom useTimeout hook, inspired by this article from Josh Comeau. It's also available in popular hooks libraries, such as usehooks-ts or @uidotdev/usehooks.
We use useReducer instead of useState to not bother passing params to the state setter, but naturally useState works as well.

Now, our Meeting component already refreshes itself at the meeting's start time automatically! 🎉
But there is still room for improvement, especially in terms of performance ⚡️ and readability 🤓

Optimizing the execution

Let’s say the meeting starts at 14:00:00, and the Meeting component first renders one minute earlier, at 13:59:00.
Now, if the Meeting component re-renders at 13:59:30 for any reason (for instance, if one of its parent components re-renders), delay will be recalculated, changing from 60 seconds to 30 seconds.

As a result, useTimeout will destroy the current timer and create a new one that will still execute at the same time, 14:00:00, since startsAt remains unchanged.
To prevent this unnecessary "clean-up", we can memoize delay so that it only changes when startsAt is updated.
Also, we don’t want to set a timer if the meeting has already started, so in that case, we set delay to null.

Now, our Meeting component will set a single timer throughout its entire lifecycle
(as long as startsAt remains unchanged), and only if the meeting has not yet started.

Encapsulate into a custom hook

Our Meeting component is becoming difficult to read, and we'd like to extract this logic into a reusable piece of code: we can create a custom useRerenderTimeout hook that takes the date at which the component should re-render as an argument.

Since the date parameter is a dependency of this useMemo, we want to ensure its reference remains stable across renders. For this reason, we define it as a string rather than a Date object.

Then, the Meeting component would look like this:

By moving the logic into a custom hook, the Meeting component only needs a single line of code to re-render itself at the desired time. ✨
This keeps the code light and clear, and offers a generic solution that's easy to use.

Trigger multiple re-renders at specific times

Let's say we now want to display a progress bar indicating the remaining time, starting 30 minutes before the meeting begins.
The Meeting component will now have a third possible status," imminent", in addition to "upcoming" and "started".
This means the component needs to re-render twice: once 30 minutes before the meeting starts, and once when the meeting starts.
To improve code cohesion, we can associate each status with the time at which it ends, which is also the time we want the Meeting component to re-render.

When Meeting mounts, it will set a timeout to trigger a re-render 30 minutes before the meeting starts.
Once this timeout executes, getMeetingStatus will be called again, returning a new value for status.endsAt, which will set a new timeout to trigger a re-render at the meeting start time.
This "call loop", based on the component's lifecycle, allows us to handle both re-renders using a single instance of the useRerenderTimeout hook. 🎉

Trigger a re-render at a regular interval of time

The "imminent" status lasts 30 minutes, but we want to avoid running a 30-minute-long animation for the progress bar.
Instead, we refresh the progress bar at 1% increments, which means updating it every 18 seconds.

While we could use the same "call loop" approach with useRerenderTimeout, it's simpler in this case to use an interval instead of a timeout, as the time between re-renders is constant.

We can create a similar hook to useRerenderTimeout that runs an interval instead of a timeout.

The interval is set via a custom useInterval hook, inspired by
this article from Dan Abramov.

Just like we did for useRerenderTimeout, we use useReducer instead of useState to not bother passing params to the state setter, but naturally useState works as well.

The interval continues as long as ms is a positive value, and it stops when ms is set to null.

Depending on the faith you have in yourself, you may want to add a safeguard to prevent unexpected excessively frequent intervals (recommended).
For example, we chose an arbitrary minimum interval of 1 second.

The ProgressBar component can then use this hook to re-render itself every 18 seconds, independently of the Meeting component:

Using this hook directly in the Progress component instead of its parent ensures that the minimum amount of JSX is updated.
In general, these hooks should be used as low as possible in the component tree.

Every 18 seconds, useRerenderInterval triggers a re-render,
recalculating remainingPercentage and automatically updating the relevant UI. ✅

Conclusion

Managing timers and intervals in React components can be tricky, and can quickly make the code hard to read and to maintain.
Creating these two hooks useRerenderTimeout and useRerenderInterval allowed us to easily implement complicated business logics based on timers and intervals in just a few lines of code.

They take advantage of the component's lifecycle, by triggering re-renders via local state updates, to keep the rest of the component's logic decoupled from its need to refresh at specific times, in a simple and generic way for a great developer experience.

TL;DR

`useRerenderTimeout` hook

Use case:

`useRerenderInterval` hook

Use case:

Click, Ship, Done: Our Journey to Effortless Deployments in JS

JuP — Thu, 26 Sep 2024 11:26:41 +0000

Starting point

At Wecasa, on the frontend side, we have 2 mobile apps that we are maintaining regularly, delivering new versions on both Android and iOS stores. Multiple teams with different scopes are working on these apps, and it's the responsibility of each team to deploy their work.

When one or more features are ready to be shipped in production, one dev has to prepare the new build. Let's dig into the different steps the developer has to do:

Merge commits that are going to prod on master
From the monorepo root, run a bash script (one bash script per app)

!! All our front code is located in one monorepo. Severals projects are living inside, including our 2 mobiles apps. Until now we had two separate bash scripts to deploy either one or the other app

The script defines the new app version number
Then it updates build.gradle and info.plist with the new version number
It creates a new tag on GitHub that will trigger a workflow on our CI. This workflow will create the actual builds and send them to the stores

And that's pretty much it.

Job done ✅

Improve the experience

Recently, we decided to improve our deployment process. But why? The old process was just working fine, right?

Well, yes, it got the job done, but a few things were missing:

Until now, we didn't have any changelog for any release. So sometimes, when you wanted to know which commit had been introduced in which specific version, it was not so easy to find out.
The version number generated by the old bash script was a patch release by default. We had to force a version number if we wanted to do a minor or major one. We wanted it to be easier to follow a proper semantic versioning notation.
It was a bash script. Bash is great, but few people know how to code in Bash, so few people were comfortable understanding the script and, furthermore, making adjustments to it.

A CLI to Rule Them All

To improve the experience of releasing, we decided to make a CLI in JS. The CLI will do all the tasks that the Bash script did and a few more.

We chose to build a CLI because:

It's interactive and fun to play with as a developer
It allows some flexibility and different options through the prompts
It's made in JS, so our tech team will be more comfortable adding updates to it

Inquirer JS

To build this CLI, we used the Inquirer library that allows us to quickly ask questions and store the responses:

  import select from "@inquirer/select";

  export const askRepo = async () =>
    select({
      message: "Choose the app you want to deploy",
      choices: REPOS.map((repo) => ({
        name: repo,
        value: repo,
      })),
    });

Bash to JS

Moving from a bash script to a JS CLI implies that we had to run bash commands in our JS environment. In order to execute bash commands in JS environment, we used the execSync method from Node a lot.

With this utility function ⬇️ , it was easy to migrate all bash commands to the JS scripts:

  import { execSync } from "child_process";
  export const executeBashCommand = (command: string) => {
    try {
      return execSync(command, {
        encoding: "utf-8",
        cwd: REPO_ROOT,
      });
    } catch (error) {
      console.error("Error executing command:", error);
    }
  };

Automatize Github release with changelogs

This refactor was also a good opportunity to create a proper release in GitHub with a clean changelog.

To do that, we used the GitHub API to retrieve the information we needed from our repo. More specifically by using Octokit .

Create a tag:

A release in GitHub is coupled to a tag. You can't have a release if it is not associated with a tag. So the first step was to create that tag:

We want the tag to reflect the type of release we want to make, so in our CLI, we now ask what kind of release we want: patch, minor or major.
Once the type of release known, we generate the version number.
Once we have the version number, we build our tag name and create it on GitHub.

// Generate a string based on the app we want to deploy, the next version number and the stores
let newTag = getNewTag({ app, stores, version: nextVersion });

// We check if this new generated tag already exists in Github before continuing
if (await isTagAlreadyExists(newTag)) {
  console.log(
    `⚠️ This tag already exists on Github, which means release ${app}-v${nextVersion} probably already exists too`
  );
  console.log(
    "Maybe this tag was published by mistake and no build has been sent to any store. You have two options:"
  );
  console.log(
    "1. You are sure that this release on Github is a mistake so you can delete it with the associated tag"
  );
  console.log(
    `2. You can choose another release number, different from ${nextVersion}`
  );

  const whatToDo = await askIfCustomVersion();
  if (whatToDo === "exit") {
    console.log("👋 Okay bye !\n\n");
    process.exit(0);
  }
  if (whatToDo === "change") {
    nextVersion = await nlThenInput({
      message: "Type the desired version number",
    });
    newTag = getNewTag({ app, stores, version: nextVersion });
  }
}

As you can see, we will also verify if this tag already exists in our repo and do specific actions in this case.

Generate release content and publish:

Now that we have a tag name, all we need to do is create a release with its appropriate changelog.

To build this changelog, we:

Get the latest release date
Fetch all the commits merged to master since this date
Create the body of the changelog, grabbing each commit message and its author
Once we have the content, the final step is to push the release to GitHub:

// #1 Get the latest release date
export const getLatestReleases = async (): Promise<Release[]> => {
  const releases = await octokit.rest.repos.listReleases({
    owner: REPO_OWNER,
    repo: REPO,
    per_page: 100,
  });
  return releases.data.sort(
    (a, b) => new Date(b.published_at) - new Date(a.published_at)
  );
};

// #2 Fetch all the commits merged to master since this date
export const getMergedCommitsFromDate = async (
  date?: string
): Promise<Commit[]> => {
  if (!date) return [];

  const commits = await octokit.repos.listCommits({
    owner: REPO_OWNER,
    repo: REPO,
    sha: "master",
    since: date,
    per_page: 100,
  });

  return commits.data;
};

// #3 Create the body of the changelog, grabbing each commit message and its author
export const getReleaseContent = (commits: Commit[], stores: AppStore[]) => {
  const mdFormattedCommits = commits.map(commitMarkdowned);
  return `## What is included?\n${mdFormattedCommits.join(
    "\n"
  )}\n\n## Stores:\n${stores.join(" and ")}`;
};

// #4 Push the release to Github
export const createRelease = async ({
  tagName,
  releaseName,
  body,
}: CreateReleaseProps) => {
  const release = await octokit.rest.repos.createRelease({
    owner: REPO_OWNER,
    repo: REPO,
    tag_name: tagName,
    name: releaseName,
    body,
    draft: false,
    make_latest: "true",
  });
  return release;
};

And it’s done 🎉 Below, you can have a quick preview of what the experience looks like in terminal for a dev who wants to release:

Conclusion

To summarize, we changed from an entire bash script that was quite intimidating for devs with no experience in bash language, to a CLI made in JavaScript, so very close to our stack. And as a result, easier to read, understand, and maintain.

We grabbed this opportunity to also create proper releases in our GitHub with changelogs, which will bring tech and product teams more transparency through a clean feature history.

	New	Old
Code	TypeScript	Bash
One script for both app	✅	❌
Changelogs in Git	✅	❌
Choice of version	✅	❌
CLI	✅	❌
Maintainability	Easier in JS	Harder because it’s bash

Thanks for reading!

Secure your Stripe Webhooks and protect yourself from Captain Hook

Antoine Braconnier — Mon, 29 Jul 2024 10:14:01 +0000

If you handle your app payments with Stripe, there's a strong chance that at some point you end up needing using their webhooks. But payments are such a sensitive matter and you certainly don't want to expose your endpoints to every pirate sailing around, now, would you?

That is why it's really important to setup secured routes without being plundered and loot by some evil corsairs! So grab a grog, and let's find out how to write a basic Stripe webhook endpoint. Following some simple recommendations, it will safely receive and process events.

Webhook security

But what is the actual risk of having a webhook endpoint exposed, cast adrift? There's two main issues :

Forged requests : someone can mimic the same data structure and send forged requests with fake data to your endpoint.

Replay attack : provided that your endpoint is HTTPS and not HTTP, no one but you can read the events sent by Stripe to you. They can, however, capture the encrypted data sent and re-send them again and again, which definitely could cause some harm.

Luckily enough, Stripe sends us something really useful in the Headers called STRIPE-SIGNATURE that looks like this:

"t=1721661059,v1=ef9344dc37fe005b41d7b9d29871cfe1287b2deefbb8d3lk10b9a74b859345734"

In this header, we have two values:

t , a timestamp,
v1 , an encrypted value generated each call that will be used in our app to verify the authenticity of the event sent.

With those two values, and the help of the Stripe SDK, we can build a Stripe::Event object in our app with the payload. This will:

Assert the data structure sent by Stripe;
Decrypt the encrypted value (v1), so we know the event is legit;
Assert that the timestamp is from less than 5 minutes ago, to mitigate the replay attack risk. We'll see that this 5 minutes value can be modified.

Now, let's implement a Stripe webhook!

Setting up a Stripe webhook endpoint

First, add an endpoint on your Stripe dashboard ( let's call it https://www.myapp.com/payments/events ) and add an event to listen to. Let's say we want to start shipping goods to the user once we have a successful payment intent. The event we want to listen to is thus payment_intent.succeeded.

Now let's go to our app and let's code a route with a matching controller. The stripe webhook endpoint is supposed to be a POST.

# config/routes.rb
Rails.application.routes.draw do
  #...
  namespace :payments do
    post :events
  end
end

# app/controllers/payments/events_controller.rb
module Payments
  module EventsController
    def create
    # ...
    end
  end
end

Ok, great, that's a good start. We have now a controller that will listen to all of your webhooks.

Building a Stripe::Event object

Now, we actually need to transform the payload into a Stripe::Event object to make sure that it is safe.

For the signature decryption, we'll need one last thing : the signing secret of the endpoint. You can find in the stripe dashboard, in the new webhook endpoint page that you just created. You can add it in your .env files, under the name PAYMENT_WEBHOOK_SECRET for example.

Then we have everything necessary to create a service to build this event. This service will accept as a parameter:

the payload, which will be a string;
and the signature header (with the v1 and t values, remember?) for the security check. We'll also need to use the stripe webhook secret.

The building of the event can raise two kind of errors in case of bad data, and it's important we handle these errors properly. So let's add a basic error handler with this in mind.

# app/services/payments/build_event_service.rb
module Payments
  class BuildEventService < ApplicationService
    WEBHOOK_SECRET = ENV.fetch('PAYMENT_WEBHOOK_SECRET').freeze

    def call(payload:, signature_header:)
      @payment_provider.construct_event(
        payload,
        signature_header,
        secret_key,
        # :tolerance argument will change the 5 minutes limit to one minute
        tolerance: 60
      )
    rescue JSON::ParserError, Stripe::SignatureVerificationError => e
      raise WebhookSecurityCheckError, e
    end
  end
end

Now, we have a service that will effectively build and return a Stripe::Event object.

Let's add it in our controller! And let's take the opportunity to think about what the controller needs to respond here. Stripe will expect a 200 response from its webhook call, so let's return that, and let's maybe return a 401 if our security check didn't pass.

# app/controllers/payments/events_controller.rb
module Payments
  module EventsController
    def create
      event = BuildEventService.new.call(payload: payload, signature_header: signature_header)
      # do stuff with the event created
      # ...
      head :ok
    rescue WebhookSecurityCheckError => e
       head 401
    end

    private

    def payload
      request.body.read
    end

    def signature_header
      request.env['HTTP_STRIPE_SIGNATURE']
    end
  end
end

Ok! We have now an endpoint that is all setup for a basic security check.

Dispatching Stripe events

However, this is still not entirely ideal. Stripe expects to receive an answer quickly. In fact, this controller should do the most minimal thing possible :

check that the event is indeed sent by Stripe,
delegate ASAP the responsability and the payload to a corresponding job.

So let's quickly add a dispatcher that will do just that. For this, we'll need to have a hash with the corresponding event types mapping to jobs.

# app/services/payments/dispatch_event_service.rb

module Payments
  class DispatchEventService < ApplicationService
    EVENT_TYPE_TO_JOB = {
      'payment_intent.succeeded' => SendProductToClientJob,
      #...
    }.freeze

    def call(event:)
      EVENT_TYPE_TO_JOB[event.type].perform_later(event: event.to_hash)
    end
  end
end

Now, we can use this dispatcher in our controller:

# app/controllers/payments/events_controller.rb
module Payments
  module EventsController
    def create
      event = BuildEventService.new.call(payload: payload, signature_header: signature_header)
      DispatchEventService.new.call(event: event)
      head :ok
    rescue WebhookSecurityCheckError => e
       head 401
    end

# [...]

Testing

For testing, you'll probably need to stub your method call construct_event to make it return what you need. And to test manually and locally the webhook, a good and easy way to do it without having to use a tool like ngrok is to use the Stripe CLI.

This is the command to install Stripe CLI via Homebrew :

brew install stripe/stripe-cli/stripe

Then login with your credentials :

stripe login

And now, you can easily forward any events necessary to your local server :

stripe listen --events payment_intent.succeeded \
 --forward-to localhost:3000/payments/events

And to trigger the webhook when necessary:

stripe trigger payment_intent.succeeded

Of course, you can go further in securing your webhook. For example, you can use the idempotency key that each event provide to make sure that the event is unique.

With this basic setup, you can already receive pretty safely Stripe webhooks, and you can add events in the EVENT_TYPE_TO_JOB whenever you need to. Your code will safely build a Stripe::Event object and check the correct event type to delegate the attributes of the payload to a matching job.

Thank you for reading. I invite you to subscribe so you don't miss the next articles that will be released.

Happy sailing (and coding)! 🦜 🏴‍☠️

Binary Decision Tree in Ruby ? Say hello to Composite Pattern 🌳

Just The V — Mon, 01 Jul 2024 07:23:16 +0000

Decision trees are very common algorithms in the world of development. On paper, they are quite simple. You chain if-else statements nested within each other. The problem arises when the tree starts to grow. If you're not careful, it becomes complex to read and, therefore, difficult to maintain.

In this article, we'll see how we implemented decision trees at Wecasa to make them as readable and maintainable as possible.

Before we go any further, let's take some time to define what a Composite is.

What Links Composite and Binary Decision Tree?

Composite is a structural design pattern. It is a way of arranging objects in a tree structure, which allows us to have a logical hierarchy.

When we talk about a decision tree, we can represent it as boxes that can contain boxes, which can contain boxes, which can contain… a final result.

It's precisely this recursive aspect that makes the decision tree so powerful.
Let's take an example. We want to create a decision tree to calculate the amount of the promotion a customer is eligible for on our e-commerce site.

In input, our tree receives a User object with all its attributes.
In output, our tree returns a number.

Each node in our tree has a condition. You can notice by the color code that we have three types of Composites here: Creation Date, Zip Code, and whether the user has already made a purchase. Now that our example is set, let's see how this translates into code!

Firstly, we need tools !

In our implementation of the decision tree, we will need three classes:

The Node Class: The base class for all other classes. Its purpose is to encapsulate the common logic for all different Nodes in my tree.

class Node
  attr_accessor :left_node, :right_node

  def call(user)
    raise NotImplementedError
  end

  private

  # this method is used to ease composites definition
  def call_with_condition(user)
    if yield
      left_node.call(user)
    else
      right_node.call(user)
    end
  end
end

The Leaf Class: Its purpose is to end the tree. You can find them as bottom nodes without any child nodes. The only job they have to accomplish is to return the value they encapsulate.

class Leaf < Node
  attr_accessor :value

  def initialize(value)
    self.value = value
  end

  def call(_)
    value
  end
end

The Composite Classes: Their role is to contain the condition to guide between the success branch and the failure branch, to proceed to the next step in the algorithm. They also contain a method to set arguments. We will see later why this method is useful.

class CreationDateComposite < Node
  attr_accessor :days

  def initialize(left_node, right_node)
    self.left_node = left_node
    self.right_node = right_node
  end

  def call(user)
    call_with_condition(user) do
      self.days.ago > user.created_at
    end
  end

  def set_days(days)
    self.days = days
    self
  end
end

class ZipCodeComposite < Node
  [...]
end

class HaveBoughtComposite < Node
  [...]
end

I only show CreationDateComposite so you understand the logic, no need to show the rest.

How We Finally Manage to Create a Binary Decision Tree

Thanks to all the classes we have built, we will now create our first complete tree. Here is the proposed implementation:

class PromotionTree
  # We use Singleton because we don't need to rebuild the tree
  # everytime we call the class
  include Singleton

  TREE = CreationDateComposite.new(
    ZipCodeComposite.new(
      BoughtComposite.new(
        Leaf.new(60),
        Leaf.new(150)
      ),
      BoughtComposite.new(
        Leaf.new(30),
        Leaf.new(100)
      )
    ).set_zip_code('75'),
    BoughtComposite.new(
      Leaf.new(30),
      ZipCodeComposite.new(
        Leaf.new(75),
        ZipCodeComposite.new(
          Leaf.new(78),
          Leaf.new(0)
        ).set_zip_code('78')
      ).set_zip_code('75')
    )
  ).set_days(7).freeze

  def call(user)
    TREE.call(user)
  end
end

And now we can simply use the tree :

user = User.last
PromotionTree.instance.call(user) # => 60 🎉

That being explained, this implementation offers several benefits:

No if-else mixed in my business logic: By encapsulating conditions in separate objects, we have a clear separation of responsibilities. Each condition is handled by a specific composite, making the code more readable, elegant and maintainable.
Centralization of conditions in separate objects: This allows easy reuse and modification of conditions without touching the main application logic. Conditions can be changed or extended by creating new composites or modifying existing ones thanks to OOP.
Ease of testing: Each component of the decision tree can be tested in isolation, simplifying the unit testing process. Tests can focus on specific conditions without having to simulate the entire decision tree.
Extensibility: Adding new conditions or modifying existing conditions is simple and straightforward. Just create new composite nodes and insert them into the existing decision tree.
It's easy to build a new tree: Let's say tomorrow I want to build a new kind of tree. I always have all my Nodes ready to be used.

But apart from this, I can see some downsides :

The setup cost is High: I think it's not that pertinent to use this if you setup this kind of architecture if you don't plan to create other trees.
It uses recursion: The limit of your tree will be the limit of your Stack Size. So if your tree is bigger than your allowed stack size, you won't be able to use it. Fortunately, this value is quite big : 10867 for my setup. But it can depend on your setup !
You need to get into the habit to read it quickly: At first it's kinda disturbing. The fact that we need to read on the top the Composite, and the bottom the value it used is quite weird. But don't be afraid of this syntax, I will publish another article to show you how I implemented a DSL for Tree building based on this architecture.

Conclusion

Using Composite to implement decision trees allows us to structure our conditions in a clear and maintainable way. Rather than getting lost in a maze of nested if-else statements, we have a logical hierarchy of decisions, each node playing a well-defined role.
Thank you for reading. I invite you to subscribe so you don't miss the next articles that will be released.

Forem: Wecasa

Letting the ducks fly: How we’re switching from Redux to React Query

1. A compelling library

2. Rethinking loading / error logic

3. How we got started

4. Challenges & corner cases

Conclusion

How to schedule an update of a React component in the future

useRerenderTimeout & useRerenderInterval : 2 custom hooks to re-render a React component at a specific time, or at a regular interval of time.

Trigger a re-render at a specific time

Optimizing the execution

Encapsulate into a custom hook

Trigger multiple re-renders at specific times

Trigger a re-render at a regular interval of time

Conclusion

TL;DR

useRerenderTimeout hook

Use case:

useRerenderInterval hook

Use case:

Click, Ship, Done: Our Journey to Effortless Deployments in JS

Starting point

Improve the experience

A CLI to Rule Them All

Inquirer JS

Bash to JS

Automatize Github release with changelogs

Conclusion

Secure your Stripe Webhooks and protect yourself from Captain Hook

Webhook security

Setting up a Stripe webhook endpoint

Building a Stripe::Event object

Dispatching Stripe events

Testing

Binary Decision Tree in Ruby ? Say hello to Composite Pattern 🌳

What Links Composite and Binary Decision Tree?

Firstly, we need tools !

How We Finally Manage to Create a Binary Decision Tree

Conclusion

`useRerenderTimeout` & `useRerenderInterval` : 2 custom hooks to re-render a React component at a specific time, or at a regular interval of time.

`useRerenderTimeout` hook

`useRerenderInterval` hook