Forem: Guilherme Ananias

How to generate dynamic OG (OpenGraph) images with Satori and React

Guilherme Ananias — Thu, 27 Jun 2024 12:16:25 +0000

Have you ever seen those great images that appear when you share any link through social media? Twitter, WhatsApp, Discord, Facebook, Slack, and everywhere display those images as a way to aggregate some context value for all the links you share. For example:

At Woovi, one of our great features is our payment link. A link that you can share with your customers and let them have access to all data related to their charges. Let the customers see the QR code to pay the Pix, the value of the charge, and any other relevant information that could be useful for them.

Sharing the Payment Link

But, what happens when we get this payment link, for example, and share it in some place? What we would see was just the QR code related to that Pix, like the example below:

But, this isn't a nice thing to see at all, do you agree? Isn't give any useful information, and I, being the customer, doesn't appreciate it. Further, the fact that, in some specific cases, they can't render the QR code because the image is greater than expected (WhatsApp, for example, only accepts 1200x630 OG images).

With that idea in mind, we put a great effort into implementing a new way to generate our OG images in runtime. The idea was: to dynamically generate the image according to some specific data, with that, we can have a better image that lets the customer appreciate what they're seeing.

Using Satori to Generate the Image

Under the hood, we would use Satori as the solution that will generate the SVG for us. We would need these things:

An endpoint that will get the request to generate the image
Satori to create the SVG

It's simple, right? The idea was to get all necessary data through this endpoint and pass it to a React component that will be rendered by Satori and converted into an SVG. Too easy, right?

Implementing the endpoint

The endpoint is simple and is like any other endpoint that you already implemented. Based on our stack, we will be using Koa.js to implement it:

import { Router } from '@koa/router';
import type { Context } from 'koa';

const router = new Router();

routerOpenPix.get(
  '/api/link/og/:paymentLinkID{.png}?',
  paymentLinkOgImageGet,
);

function paymentLinkOgImageGet(ctx: Context) {
  // let's implement it in another moment, okay?
}

The idea of this endpoint is simple: get the param paymentLinkID and find all the data through our materialized data into our database and pass it to the Satori.

Rendenring the SVG

Now that we already implemented the endpoint, we can follow the usage of the Satori to render our image for us:

import type { Context } from 'koa';
import satori from 'satori';

async function paymentLinkOgImageGet(ctx: Context) {
  const { paymentLinkID } = ctx.params;

  const paymentLink = await getPaymentLinkByID(paymentLinkID);

  if (!paymentLink) {
    ctx.status = 400;
    ctx.body = 'Error';
    return;
  }

  let svg: string | undefined;

  try {
    const font = await loadFontInArrayBuffer();

    svg = await satori(
      <div style={{ width: 1200, height: 630 }}>
        <h1>{paymentLink.title}</h1>
      </div>,
     {
       fonts: [
        {
          name: 'Font',
          data: font,
          style: 'normal',
          weight: 400,
        },
      ],
    });

    ctx.set('Content-Type', 'image/png');
    ctx.status = 200;
    ctx.body = svg;
  catch (err) {
    ctx.status = 400;
    ctx.body = err;
  }
}

I'll explain to you what we're doing here:

We're finding and validating if the paymentLink really exists.
Satori requires at least 1 font loaded as an array buffer, so we're loading one here. In that case, you can follow your preferrable way to do it. Load a font from Google Fonts, get it from local assets, and do what you prefer here.
We're calling the satori function that will render the SVG for us based on the JSX that we pass (under the hood, they're converting it into an object).

Just a specific detail about CSS on Satori. Satori under the hood uses Yoga to render things, so they can't accept the entire set of CSS rules, just a subset of them. You can see here all the rules that are being accepted by them.

If everything goes right, you can access this endpoint and validate that the SVG has been right rendered for you.

If necessary, you will need to return it as an image by itself. For that, we can use the sharp to handle it for yourself. See the example below:

  const svg = await satori(); // render the svg
  const img = await sharp(Buffer.from(utf8.decode(svg)))
    .png()
    .toBuffer()

Adding the metatag on HTML

Now that you already rendered the new OG, you will need to add this into your HTML to ensure that all crawlers will get it.

For that, you just need to add two new tags to your <head> tag. See below:

<!DOCTYPE html>
<head>
  <meta property='og:image' content="https://yoururl.com/api/link/og/<dynamic-payment-link-id>.png" />
  <meta property='twitter:image' content="https://yoururl.com/api/link/og/<dynamic-payment-link-id>.png" />
</head>
<!-- ... -->

As already commented in another post, we render our entire payment link using an SSR strategy, so we can insert the <dynamic-payment-link-id> properly just getting their identifier. You'll need to validate what is the better way to do it by your side.

Both og:image and twitter: image metatags will ensure that the new OG image will be rendered in all social media and chats.

Conclusion

With that implementation, we go from that old QR code that was being rendered to our customers, to this new one below:

With that new OG, we can: get the merchant's name, how much the customer will pay for them, the expiration date, and the QR code in a more readable way.

Further, by the fact that this is dynamically rendered, we can improve our OGs in runtime to render other states like payment link paid, expired, and different scenarios too.

This is how powerful OGs can be in general.

Visit us at Woovi!

Photo by Hassaan Here on Unsplash

Implementing Simple Paxos Consensus Algorithm With Rust

Guilherme Ananias — Tue, 13 Feb 2024 16:15:07 +0000

What Is Consensus?

I would say that one of the core properties of a system is the agreement on which data
are right at a given moment.

At that moment, one of the more important aspects of a distributed system shows up:
the consensus. Where every participant agrees on a single state, even if some actor
fails.

Some use cases where consensus brings a strong advantage are network agreement in a
server cluster, database replicati ons, and even in blockchain networks.

The Simple Paxos

The Simple Paxos algorithm is the most simple implementation of the Paxos Protocol family.
As presented by Leslie Lamport on the The Part-Time Parliament
and Paxos Made Simple,
the idea of the Simple Paxos is simple:

Your node can assume 3 different roles: proposers, acceptors and learners.
Your node can be all these roles at the same time.
An acceptor will accept the first value that is received as a proposal.
A proposer will receive a promise from every acceptor, that promise let the proposer knows that the node will accept the proposed value.
A proposer reach the quorum, that is, the majority, when receive a promise of $N/2 + 1$ where $N$ is the number of nodes in the system.
After reach the quorum, the learners will receive the accepted value from the acceptors. The learners will put the accepted value into their state machines.

Preparing the proposal for a new value

A proposer is the node that will propose a new value to reach the consensus
around their system. In this case, each proposal follows this pattern: (id, v),
where the id is an incrementally natural number, and v is the proposed value,
for our implementation, we will assume v as a string.

First things first. We need to start our server. In this case, using Rust, I will
use Axum to do all the work for me:

use Axum::{
    routing::{get, post},
    Router,
    http::StatusCode,
    extract::{State, Json}
};
use clap::Parser;
use serde::{Serialize, Deserialize};
use tokio::sync::Mutex;

type Ledger = HashMap<Id, Value>;
struct AppState {
    node: Node,
    nodes: Arc<Mutex<Vec<Node>>>,
    acceptor: Arc<Mutex<Acceptor>>,
    proposer: Arc<Mutex<Proposer>>,
    ledger: Arc<Mutex<Ledger>>,
}

#[derive(Parser, Debug)]
#[command(author, version, about, long_about = None)]
struct Args {
    #[arg(long)]
    id: u64,
    #[arg(short, long)]
    port: String,
}

#[tokio::main]
async fn main() {
    let args = Args::parse();
    let port = args.port;
    let node_id = args.id;

    let node_http_addr = format!("0.0.0.0:{}", port);

    println!("Starting new node: http://{}", node_http_addr);

    let node = Node::new(node_id, node_http_addr.parse().unwrap());
    let state = AppState {
        node,
        nodes: Arc::new(Mutex::new(Vec::new())),
        acceptor: Arc::new(Mutex::new(Acceptor::default())),
        proposer: Arc::new(Mutex::new(Proposer::new())),
        ledger: Arc::new(Mutex::new(HashMap::new())),
    };

    let app = Router::new()
        .route("/prepare", post(prepare))
        .route("/handle-prepare", post(handle_prepare))
        .with_state(state);

    let listener = tokio::net::TcpListener::bind(node_http_addr).await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

#[derive(Clone, Debug)]
struct Proposer {
    pub id: u64,
}

impl Proposer {
    pub fn new() -> Self {
        Self {
            id: 0,
        }
    }

    pub async fn prepare(&mut self, state: &AppState, value: String) -> Result<Proposal, String> {
      todo!()
    }

    pub async fn propose(&self, state: &AppState, propose: &Proposal) -> Result<(), String> {
      todo!()
    }
}

#[derive(Clone, Debug, Default)]
struct Acceptor {
    pub last_proposal_number: u64,
    pub accepted_proposal: Option<Propose>,
}

#[derive(Serialize, Deserialize, Debug)]
struct Proposal {
    pub id: u64,
    pub value: Option<String>,
}

async fn prepare() -> () {
  todo!()
}

async fn handle_prepare() -> () {
  todo!()
}

Now, we have a server running on the port that we want. You can test it by running:

cargo run -- --id 1 --port 3000

We will implement the proposer logic on the /prepare endpoint. The proposer
will send a prepare message to all acceptor messages and wait
for the promises.

async fn prepare(State(state): State<AppState>, value: String) -> (StatusCode, String) {
    let mut proposer = state.proposer.lock().await;
    let proposal = match proposer.prepare(&state, value).await {
        Err(e) => return (StatusCode::BAD_REQUEST, e.clone()),
        Ok(proposal) => proposal,
    };

    todo!()
}

In this first phase, we will only send the prepare message to all acceptors. The
prepare message is a simple message with the id of the proposal. The acceptor will
receive this message and will send a promise to the proposer.

impl Proposer {
    // ...

    pub async fn prepare(&mut self, state: &AppState, value: String) -> Result<Proposal, String> {
        let client = Client::new();

        self.id += 1;

        let nodes = state.nodes.lock().await;
        let reqs = nodes.iter().map(|node| {
            client.post(format!("http://{}/handle-prepare", node.addr))
            .json(&self.id)
            .send()
        });

        let responses = futures::future::join_all(reqs).await;

        let mut promises = Vec::with_capacity(responses.len());

        for response in responses.into_iter().flatten() {
            promises.push(response.json::<HandleProposalPayload>().await.unwrap());
        }

        let quorum = (nodes.len() / 2) + 1;

        if promises.len() < quorum {
            return Err(String::from("Proposal does not receive promises of the entire quorum"));
        }

        let accepted_promise = promises
            .into_iter()
            .filter(|promise| promise.value.is_some())
            .max_by_key(|promise| match &promise.value {
                None => 0,
                Some(value) => value.id,
            });

        // Sorry, I'm not proud of it, but it's the best that I can do for now. :(
        // Feel free to improve it (PLEASE!).
        let value = match accepted_promise {
            None => Some(value),
            Some(payload) => {
                match payload.value {
                    None => Some(value),
                    Some(proposal) => {
                        match proposal.value {
                            None => Some(value),
                            b => b,
                        }
                    },
                }
            }
        };

        let proposal = Proposal { id: self.id, value };

        Ok(proposal)
    }
}

We implement the proposer.prepare method to send the prepare message to all acceptors. What
this is doing is:

Calling the /handle-prepare endpoint of all nodes in the system.
Waiting for the promises of the acceptors.
Checking if the proposer received the quorum of promises.
If the proposer received the quorum, it will check if there is a value that was accepted by the acceptors. If there is, the proposer will use this value as the proposed value. If not, the proposer will use the value that it wants to propose.
Return the proposal.

Receiving the prepared value and sending the promise

Cool. We're coming to what we can call the phase 1b. The acceptor will receive
the prepare message and need to send a promise if everything is OK. In this case, which
things do we need to check?

If the proposal number is greater than the last proposal number that the acceptor received.
If the acceptor already accepted a value, if yes, it needs to send the accepted value to the proposer.

#[derive(Serialize, Deserialize, Debug)]
struct HandleProposalPayload {
    error: Option<String>,
    value: Option<Proposal>,
}

async fn handle_prepare(State(state): State<AppState>, proposal_id: String) -> (StatusCode, Json<HandleProposalPayload>) {
    let proposal_id: u64 = proposal_id.parse().unwrap();
    let mut acceptor = state.acceptor.lock().await;

    if proposal_id <= acceptor.last_proposal_number {
        let payload = HandleProposalPayload {
            error: Some(String::from("The proposal ID is lesser than the last accepted proposal number")),
            value: None,
        };
        return (StatusCode::BAD_REQUEST, Json(payload));
    }

    if acceptor.accepted_proposal.is_some() && acceptor.last_proposal_number == proposal_id {
        let value = acceptor.accepted_proposal.clone();
        let payload = HandleProposalPayload {
            error: None,
            value: Some(Proposal { id: proposal_id, value }),
        };
        return (StatusCode::OK, Json(payload));
    }

    acceptor.last_proposal_number = proposal_id;

    let payload = HandleProposalPayload {
        error: None,
        value: Some(Proposal { id: proposal_id, value: None }),
    };

    (StatusCode::OK, Json(payload))
}

We improved the handle-prepare function to handle all the logic of the acceptor
receiving the prepare message, instead of just a todo!(). If everything is OK,
the acceptor will return a promise to the proposer. If not, it will return an error
message.

Receiving the promise and handling the acceptance message

Now that the proposer received the promise, we need to start with the phase 2a.
The proposer will send the accept message to all acceptors. The accept message needs
to contain the proposal and their identifier.

Then, the first part of our implementation will be improving the implementation of our
Proposer struct. In this case, we will need to add a new function called propose.

#[derive(Serialize, Deserialize, Debug)]
struct HandleAcceptPayload {
    error: Option<String>,
    value: Option<Proposal>,
}

impl Proposer {
    // ...

    pub async fn propose(&self, state: &AppState, proposal: &Proposal) -> Result<(), String> {
        let client = Client::new();
        let nodes = state.nodes.lock().await;

        let reqs = nodes.iter().map(|node| {
            client.post(format!("http://{}/handle-accept", node.addr))
                .json(&proposal)
                .send()
        });

        let responses = futures::future::join_all(reqs).await;

        let mut accepted_promises = Vec::with_capacity(responses.len());

        for response in responses.into_iter().flatten() {
            accepted_promises.push(response.json::<HandleAcceptPayload>().await.unwrap());
        }

        let quorum = (nodes.len() / 2) + 1;

        if accepted_promises.len() + 1 < quorum {
            return Err(String::from("Proposal not accepted by majority"));
        }

        Ok(())
    }
}

This propose function will send the accept message to all acceptors and wait for the
acceptance of the proposal. If the proposer receives the quorum of acceptances, it will
return Ok(()). If not, it will return an error message.

Now, we need to implement the /handle-accept endpoint to handle the accept message.

async fn handle_accept(State(state): State<AppState>, propose: Json<Proposal>) -> (StatusCode, Json<HandleAcceptPayload>) {
    let mut acceptor = state.acceptor.lock().await;
    if acceptor.last_proposal_number != propose.id {
        let payload = HandleAcceptPayload {
            error: Some(String::from("Node received a proposal with a proposal ID different!")),
            value: None,
        };
        return (StatusCode::BAD_REQUEST, Json(payload));
    }

    acceptor.accepted_proposal = propose.value.clone();

    let payload = HandleAcceptPayload {
        error: None,
        value: Some(Proposal { id: propose.id, value: propose.value.clone() }),
    };

    (StatusCode::OK, Json(payload))
}

Now, we have the acceptor receiving the accept message and handling it. If everything
is OK, the acceptor will accept the proposal and return an acceptance message to the
proposer.

We will need to add the proposer.propose call on the /prepare endpoint.

async fn prepare(State(state): State<AppState>, value: String) -> (StatusCode, String) {
    // ...

    match proposer.propose(&state, &proposal).await {
        Err(e) => (StatusCode::BAD_REQUEST, e),
        Ok(_) => {
            let client = Client::new();
            let nodes = state.nodes.lock().await;

            let reqs = nodes.iter().map(|node| {
                client.post(format!("http://{}/handle-learn", node.addr))
                    .json(&proposal)
                    .send()
            });

            futures::future::join_all(reqs).await;

            (StatusCode::OK, String::from("Proposal accepted by the majority!"))
        },
    }
}

Removing that old todo!() and putting the proposer.propose call on the /prepare,
we have the proposer sending the accept message to all acceptors and waiting for
the acceptance of the proposal. If the proposer receives the quorum of acceptances,
it will send the accepted value to all learners.

Learning the accepted value

The last part of our implementation is the /handle-learn endpoint. The learner
will receive the accepted value and put it into their state machines.

async fn handle_learn(State(state): State<AppState>, payload: Json<Proposal>) -> (StatusCode, ()) {
    let mut ledger = state.ledger.lock().await;
    match &payload.value {
        None => ledger.insert(payload.id, String::from("")),
        Some(v) => ledger.insert(payload.id, v.clone()),
    };
    (StatusCode::OK, ())
}

After learning the accepted value, the learner will put it into their state machines. And
then we have the consensus around the system. The acceptor will
send the accepted value to the learner, but I think it's easier to implement
just sending the accepted value to the learner via proposer.

Conclusion

This is the most simple implementation of Paxos Protocol consensus algorithm.
You have some variants that brings some improvements to the Paxos, like the
Multi-Paxos and EPaxos. All of these have some properties that are best for
specific use cases.

If you want to see the repo with the implementation of this algorithm, you can
access it here.

Thanks to hnrbs, one of my inspirations to write this
code and learn more about Paxos and consensus.
You can see his implementation here.

How To Write Material UI Components Like Radix UI And Why Component Composition Matters?

Guilherme Ananias — Wed, 17 Jan 2024 10:53:13 +0000

One of the core strengths of React is its components. Components are just functions, and like them, you can abstract them into a way that you can couple it matching multiple scenarios in your codebase.

Having components with the ability to be composed in different scenarios gives you a powerful way to write your front-end kinds of stuff.

Think that you have a state that handles the opening state of a modal, but your entire modal scope has written in multiple, different components, and has 5 or 6 levels of nesting between the children. How many components you will need to pass the setOpen and open props, or even write a context that shares the state between all the component trees?

It won't scale and will be too boring to write and maintain it. It's the kind of code that does not need to be overcomplicated, right? Then, why not handle these primitive components more easily?

Radix UI and The Composition Flow

In my opinion, Radix UI is one of the best component libraries in the React environment at the moment. It's really cool what they're doing around this library and the approach to improving the developer experience with the components.

The example that we will use for today comes from the Dialog, as you can see accessing their documentation, the Dialog component is composed of some useful components: Root, Trigger Content, Title, Close and others.

Right, but why does it matter? Because these components give you the ability to compose the Dialog tree. Like this image below:

In this case, we will have two different dialogs: A and B. Both have their own actions with their own props like each one has a different color, but both share the same content. You just need to import this component into the tree and everything will work as expected.

This is the magic of composing components.

Material UI And Radix UI, Not Enemies, But Friends

Here, at Woovi, our design system has been wrote using [MUI](https://mui.com/. But, in my opinion, I have some pain points considering how MUI built their components, most focusing on the fact of how they expose their component APIs and how they handle the component structure.

As a reference, see how they built the Dialog component, it would fail down into the same problem that I mentioned before, you would need a way to handle the entire logic for handling open state by your own hand, and you don't have a way to escape from that.

Thinking about that, so why not combine business with pleasure? It's when I reached the idea of writing our components following the same philosophy from Radix, that it should have the ability of being composed.

It's All About Context

At that moment, I opened the Radix UI repository and started to understand how things work under the hood and how could I reimplement it into our scenario. In this case, the magic behind Radix is just contexts and how they use it in a cool way.

As you can see in the code here, what they have a function called createContextScope that will provide for you a function that creates your context and another function that will give a composed scope for your new component. It's an approach to avoid collision between contexts if you have two or more components nested.

What matters in fact for us is just the context for now. You can see how they're building it here: createContextScope. Now, using this function, you'll reach this behavior:

const [DialogProvider, useDialogContext] = createDialogContext<DialogContextValue>('Dialog');

In this case, it gives you the DialogProvider component which will be what we want here. The useDialogContext is just a simple abstraction over the useContext, we'll assume this:

const useDialogContext = () => {
  const context = React.useContext(DialogContext);

  if (!context) {
    throw new Error("Should be used only inside DialogContext scope");
  }

  return context;
}

Now, that you know everything that happens under the hood in Radix, what we will do is:

Share every state that you want to be accessed by the children in the provider;
write the components that will be consumed by this dialog;

Let's see how I implemented it in our codebase.

Dialoguing For Us

The first step should be to write our context provider, in our case, we will call this the Dialog, right?

// Dialog.tsx
type DialogContext = {
  open: boolean;
  setOpen: React.Dispatch<React.SetStateAction<boolean>>;
};

const DialogContext = createContext<DialogContext | null>(
  null,
);

export const useDialogContext = () => {
  const context = useContext(DialogContext);

  if (!context) {
    throw new Error('Only should be used on the Dialog scope');
  }

  return context;
};

const Dialog = (props: DialogProviderProps) => {
  const { children, isOpen = false } = props;

  const [open, setOpen] = useState(isOpen);

  const value: DialogContext = {
    open,
    setOpen,
  };

  return (
    <DialogContext.Provider value={value}>
      {children}
    </DialogContext.Provider>
  );
};

This will be our core component, it's where all the logic around their state will work.

Now, we'll need three things that are missing, right? The title of the dialog, the button to open, and the content. Let's start writing the trigger:

// DialogTrigger.tsx
import React from 'react';

import { useDialogContext } from './Dialog';

type DialogTriggerProps = {
  children: React.ReactNode;
  onClick?: React.MouseEventHandler<HTMLElement>;
};

export const DialogTrigger = (props: DialogTriggerProps) => {
  const { setOpen } = useDialogContext();
  const { children, ...triggerProps } = props;

  const handleToggleOpen = () => {
    setOpen(true);
  };

  const handleOnClick = () => {
    triggerProps.onClick();
    handleToggleOpen();
  }

  // the cloneElement here is just a simplified way of the `asChild` similar behavior, I rewrote the same component injecting the new props
  return React.cloneElement(children as React.ReactElement, {
    ...triggerProps,
    onClick: handleOnClick,
  });
};

With the DialogTrigger written, now we can be able to open the dialog, but we'll need to display both the title and content yet:

// DialogContent.tsx
import Box from '@mui/material/Box';
import Modal from '@mui/material/Modal';
import Paper from '@mui/material/Paper';
import DialogContent from '@mui/material/DialogContent';
import DialogTitle from '@mui/material/DialogTitle';
import { useTheme } from '@mui/material/styles';
import type { SxProps } from '@mui/material/styles';
import React from 'react';

import { useDialogContext } from './Dialog';
import { composeStyles } from '../utils/composeStyles';

type DialogModalProps = {
  children: React.ReactNode;
  sx?: SxProps;
};

// this is the core component, it's where all the modal content will be wrapped into
export const DialogModal = ({
  children,
  sx,
}: DialogModalProps) => {
  const theme = useTheme();
  const { open, setOpen } = useDialogContext();

  const handleCloseModal = () => {
    setOpen(false);
  };

  return (
    <Modal
      open={open}
      onClose={handleCloseModal}
      closeAfterTransition
    >
      <Paper>
        {children}
      </Paper>
    </Modal>
  );
};

type DialogContentProps = {
  children: React.ReactNode;
  dividers?: boolean;
  sx?: SxProps;
};

// the root component for the dialog data area
export const DialogContent = (props: DialogContentProps) => {
  const theme = useTheme();

  const { children, dividers = true, sx } = props;

  return (
    <Box sx={{ display: 'flex' }}>
      <DialogContent dividers={dividers}>{children}</DialogContent>
    </Box>
  );
};

// the title for the dialog modal
export const DialogTitle = (props: DialogTitleProps) => {
  const { children } = props;
  return <DialogTitle id='dialog-title'>{children}</DialogTitle>;
};

Cool. So now, we have almost everything, it's just missing the last component: the actions of each dialog, where the buttons that will do something will appear.

// DialogActions.tsx
import DialogActions from '@mui/material/DialogActions';

type DialogActionsProps = {
  children: React.ReactNode;
};

export const DialogActions = (props: DialogActionsProps) => {
  const { children } = props;
  return <DialogActions>{children}</DialogActions>;
};

Cool. With it, we will have a similar behavior to that found in Radix UI components. As an example, you can write one dialog component like this:

import { Dialog } from './Dialog';
import { DialogActions } from './DialogActions';
import { DialogContent, DialogTitle, DialogModal } from './DialogContent';
import { DialogTrigger } from './DialogTrigger';

export const FeatureDialog = () => {
  return (
    <Dialog>
      <DialogTrigger>
        <button>Open</button>
      </DialogTrigger>
      <DialogModal>
        <DialogTitle>Any title here because I don't have a cool idea</DialogTitle>
        <DialogContent>
          <p>Cool modal!</p>
        </DialogContent>
        <DialogActions>
          {/* insert some actions here */}
        </DialogActions>
      </DialogModal>
    </Dialog>
  );
}

Without handling any state, just a clean JSX with all things handled under the hood. I'm biased, but I think that it's beautiful.

Conclusion

Composition is a good pattern around your codebase, it's easier to maintain and scale in your front-end components.

As I said, Radix is one of the best component libraries in the React environment at the moment, they have a lot of cool philosophies that you can share into your own UI library or replicate for the library that you want like I do with MUI.

In case, if you are curious, I suggest you do a deep dive into the Radix components, it's really cool to see how they implemented some kinds of stuff, they REALLY did a great job on that.

Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Julia Kadel on Unsplash

How To Handle Data With GraphQL Relay Client Schema Extensions

Guilherme Ananias — Tue, 16 Jan 2024 11:00:35 +0000

GraphQL Relay is one of the most powerful GraphQL clients that you can found on the web environment. It provides to you a lot of features that lets your development flow in a scalable way.

One of these great features are the client schema extensions, it's a way to extends your data coming from server with a kind of data managed on the client-side in the way you want.

In this scenario, we found the client schema extensions as an easier way to fits all our needs around the consumption of the data: needs to be easier consumed through all the application and should be managed by the Relay infrastructure, most focusing in the Relay Store.

This approach will let you sync an external store like Redux, Zustand or any other third-party global state management library into a Relay friendly way.

Extending My GraphQL Schema

The first step to handling client schema extensions in your codebase is to set up the schema extensions. For it, you will need to update your relay.config.js:

// relay.config.js
module.exports = {
  // ...
  schemaExtensions: ['./src/'],
}

In this case, the schemaExtensions will target a set of paths targeting directories that contains a *.graphql file to extend.

After that, you just need to write a new *.graphql file that will add some new type and compile it using the relay-compiler.

# client-schema.gql
type User {
  name: String!
  age: Int
}

type UserEdge {
  node: User
  cursor: String!
}

type UserConnection {
  count: Int
  totalCount: Int
  startCursorOffset: Int!
  endCursorOffset: Int!
  pageInfo: PageInfoExtended!
  edges: [UserEdge]!
}

extend type Query {
  users(
    first: Int
    after: String
    last: Int
    before: String
  ): UserConnection!
}

In this case, what we're doing is extending the type Query of our schema with a new query called users, it will let us query all the users in our Relay Store and give an entire paginated data based on Connection Pagination Pattern.

You'll be able to run the relay-compiler command with the schema extension now.

Managing The Data in The Store

Now that you have your extended schema, you can manage all client data handling it via Relay Store. For it, you'll need to use a helper function called commitLocalUpdate, it'll give you all the tools to let you commit and update data in your Relay Store.

import { commitLocalUpdate, ConnectionHandler } from 'react-relay';

const appendNewUser = (environment, data) => {
  commitLocalUpdate((store) => {
    const root = store.getRoot(); // get the root node on the relay store

    const connection = ConnectionHandler.getConnection(
      root,
      'UserListClientQuery_users', // this is the key of the @connection that will consume it
    );

    const edgeNumber = connection.getLinkedRecords('edges').length;

    const dataId = createRelayDataId(row.id, 'User'); // this is just a util function to generate a global ID for this new entry on store

    const node = store.create(dataId, row.__typename);

    node.setValue(dataId, 'id');

    const edgeId = `client:root:users:${node.getDataID().match(/[^:]+$/)[0]}:edges:${edgeNumber}`;

    // assign all values for this node
    Object.keys(data).forEach((key) => {
      const value = data[key];
      recordProxy.setValue(value, key);
    });

    // this will create the UserEdge node
    const edge = store.create(
      edgeId,
      'UserEdge',
    );

    // will assign the User node in the edge as a __ref
    edge.setLinkedRecord(node, 'node');

    const newEndCursorOffset = connection.getValue('endCursorOffset');
    connection.setValue(newEndCursorOffset + 1, 'endCursorOffset');

    const newCount = connection.getValue('count');
    connection.setValue(newCount + 1, 'count');

    // insert new connection as the last item on the connection array, like the push() method
    ConnectionHandler.insertEdgeAfter(connection, edge);
  });
}

The function above is just a helper to abstract how we'll add new users to the Relay Store. After writing it, you can use it like this:

// UserList.tsx
import { useRelayEnvironment, useClientQuery, graphql } from 'relay-react';

const UserList = () => {
  const environment = useRelayEnvironment();

  const query = useClientQuery<UserListClientQuery>(
    graphql`
      query UserListClientQuery {
        users(first: 10)
        @connection(key: "UserListClientQuery_users", filters: []) {
         edges {
            node {
             id
             name
              age
            }
          }
        }
      }
    `,
    {}
  );

  const handleAddNewUser = () => {
     appendNewUser(environment, {
       id: randomUserId(), // just a function to randomize an id
       name: randomUserName(), // just a function to randomize name
       age: randomUserAge(), // just a function to randomize age
     });
  }

  return (
    <>
      <button onClick={handleAddNewUser}>Add User</<button>
      <div>
        {query.users.edges.map(node => (
          <p key={node.id}>
            {node.name} - {node.age}
          </p>
        ))}
      </div>
    </>
  );
}

The useClientQuery is a helpful hook that lets you query ONLY client data. In this component, we're doing two things: listing all the users from the Relay Store and committing new users to the Relay Store.

Now, all your data related to the UserConnection that has been persisted in your store is easily managed by your component.

Initializing The Local Data

By default, every data in the store will start with an undefined value. For scenarios where this does not match the expectation that we want, like our example handling a connection array, we can easily initialize the local data with another value.

For this, you'll need to use the commitLocalUpdate before querying any local data, in this case, you can use it when you setup your Relay Environment. See the example below:

// relay/Environment.tsx
import { Environment, commitLocalUpdate } from 'relay-runtime';

const env = new Environment({
  // ...
});

commitLocalUpdate(env, (store) => {
  const connection = store.create('client:root:users', 'UserConnection');
  connection.setLinkedRecords([], 'edges'); // add an edge field with empty __refs
  connection.setValue(0, 'count');

  const root = store.getRoot();
  root.setLinkedRecord(
    connection,
    '__UserListClientQuery_users_connection', // this is the key of queried connection when persisted in the relay store
  );
});

With this approach, you'll be able to access the client query in your first render with an empty connection. You can replicate this idea for other similar data too.

Other Resources

If you're curious about how powerful is client schema extensions, I suggest you read more about them on the Client Schema Extensions documentation, it gives you an idea of how to use it.

Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to work with us, we are hiring!

Photo by Pankaj Patel on Unsplash

Design System 101: Top-down Approach in Component Spacing

Guilherme Ananias — Thu, 21 Sep 2023 11:32:30 +0000

Here at Woovi, one of our core philosophies around the front-end is ensure that our entire UI will be resilient around any future change. In the startup scenario, we need to iterate faster in our front-end and produce a high-quality code even in this scenario.

One of the principles that serves as a guarantee of a good code in the UI is related to how we handle the spacing between children elements. In general, we will find two different approaches: top-down and bottom-up.

Bottom-up

A bottom-up approach implies in the children elements causing a side-effect in the next (or close) elements. Rules like margin, when used to determine the spacing between two or more elements, is a bottom-up.

This can be called a bad practice. But why? In the example above, each child has their own margin rule applying 8px to the next element.

In this scenario, you're creating more entropy around your codebase. You give the power to these children to determine how they will behave in the macro UI, causing an undesirable side-effect around other elements. If one of these elements has a different spacing value, like 12px to margin-bottom, will be harder to debug and identify in which of these elements is the issue.

The CSS logic around this approach would be more harder to handle too. How do you ensure that the last element won't apply another margin-bottom? You have some ways to ensure it, but it's the kind of code that is useless because someone already solved to you.

If someone wants to change the spacing between elements from 8px to 12px, instead of changing only one element, you'll need to deep dive around the children finding where we're putting these margins and modify it, then you modify 3 (three) elements instead of only 1 (one).

Top-down

This is an example of top-down spacing. With this pattern, the parent element applies the spacing around their children. With a flexbox, you put a gap rule in the parent element and add the spacing around the children elements.

You're reducing the entropy around this code. You apply this rule only for the children elements, not having an external side-effect around other elements that aren't related to this scope. Putting the rule inside only one element is a better practice too, it's easier to debug and find around if necessary.

When `margin` rule can be applied?

A margin rule is unnecessary in almost every case. But can be acceptable given some context, for example, a spacing between a heading, and the rest of their siblings. MaterialUI provide to us an example of it, exposing a gutterBottom prop that adds a margin-bottom of 8px in the Typography element. In cases like that, where you want to add some spacing between the heading element and the "rest of the body", a margin is acceptable.

Another scenario are insets, like the Inset exposed by the Radix UI. Is a good practice around design stuffs to give a better centralization around some icons and other related stuffs, a good way to do it is using margin. It gives to you an easier way to centralize an element with a more predictable way around a specific parent.

About us

Woovi is a startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

We are hiring!

Server-side Rendering (SSR) From Scratch with React

Guilherme Ananias — Wed, 30 Aug 2023 14:17:20 +0000

A core feature at Woovi is our payment link. It's an easy way to sell anywhere on the web you don't need a website or anything else. Just send a link and get paid.

Why Use Server-side Rendering?

How can we ensure a good user experience sharing this link through the web? I would like to display the QR code related to that charge and, when sending it anywhere on the web, it should display the OGs and metatags related to that HTML page.

You don't have it with a client-side rendered page because you can't store these references until access the page.

This is the reason why we opted for SSR over CSR for our payment link. We would like to ensure that, in any place on the web, if you share the link, it should display: the right title of the payment link, the QR code as the OG image, and any other dynamic metadata.

Starting Server

The initial step is to create our entry point, from where the page will be rendered. In this case, we will use the koa framework.

// index.ts
import Router from '@koa/router';
import Koa from 'koa';
import bodyparser from 'koa-bodyparser';

const router = new Router();
const app = new Koa();

router.get('/(.*)', async (ctx) => {
  ctx.status = 200;
  ctx.body = 'OK';
});

app.use(bodyparser());
app.use(router.routes());
app.use(router.allowedMethods());

export default app;

What we're doing here is: creating a new endpoint that catches all requests and returns a 200 with an OK body. If the user hits the / or /foo/bar, it will get the same response.

Now, to run the server and open a port to access the server, you can run the code below:

// index.ts
import http from 'http';

const currentHandler = app.callback();
const server = http.createServer(app.callback());

server.listen(4000, (error) => {
  console.log(error);
});

Now, we can run all this server reaching the port 4000. If you want to test, build it with tsup or any other way that you want, like ts-node.

Rendering UI

Now, what we need is a way to render our React components, right? So the idea is to use the solutions provided by react-dom/server and handle it. Let's see the code below:

// index.ts
import Koa from 'koa';
import Router from '@koa/router';
import http from 'http';
import { renderToPipeableStream } from 'react-dom/server';

import { App } from './App';

const router = new Router();
const app = new Koa();

router.get('/(.*)', async (ctx) => {
  let didError = false;
  try {
    // Wraps into a promise to force Koa to wait for the render to finish
    return new Promise((_resolve, reject) => {
      const { pipe, abort } = renderToPipeableStream(
        <App />,
        {
          bootstrapModules: ['./client.js'],
          onShellReady() {
            ctx.respond = false;
            ctx.status = didError ? 500 : 200;
            ctx.set('Content-Type', 'text/html');
            pipe(ctx.res);
            ctx.res.end();
          },
          onShellError() {
            ctx.status = 500;
            abort();
            didError = true;
            ctx.set('Content-Type', 'text/html');
            ctx.body = '<!doctype html><p>Loading...</p><script src="clientrender.js"></script>';
            reject();
          },
          onError(error) {
            didError = true;
            console.error(error);
            reject();
          }
        },
      );

      setTimeout(() => {
        abort();
      }, 10_000);
    })
  } catch (err) {
    console.log(err);
    ctx.status = 500;
    ctx.body = 'Internal Server Error';
  }
});

app.use(router.routes());
app.use(router.allowedMethods());

const server = http.createServer(app.callback());

server.listen(3000, () => {
  console.log('Server listening on port 3000');
});

What we're doing here is: using the onShellReady function, we're inserting the chunk into the writable stream and finishing the response. It'll resolve the Suspense component and display it for the final user.

We need to wrap this flow into a Promise to ensure that Koa will wait until the resolution of the promise, which implies the resolution of the writable stream, returning the right HTML code.

The App component is your root project, in the case of the example, I just write a Hello, world! as you can see here. But you can insert anything you want.

You can see here the code.

In Conclusion

With this simple setup, you can have a powerful tool in your hand that provides our final users a better experience giving them a better SEO, a fast loading time, and other useful things that SSR brings to us for some specific cases.

But a valid question is: Why not use a template like Handlebars? For the use case inside Woovi, templates won't help us because we would need two core points: reuse our design system and ensure the usage of GraphQL in our payment link.

Inside Woovi, our entire codebase is managed by GraphQL using the Relay client framework. To ensure the best UX possible for our final user, we give some useful features in our payment link, like the real-time update after paying a charge. It's all handled by our GraphQL, which won't be solvable by templates in our use case.

This is an overview about how we handle internally our SSR stuffs. To be a production-ready code has some incrementally stuffs that needs to be done.

About us

Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

If you want to have good challenges like creating a powerful solution using Server-side rendering + GraphQL from scratch, join us!

We are hiring!

Avoiding UI Regressions With Jest

Guilherme Ananias — Tue, 07 Mar 2023 13:41:21 +0000

How can you ensure that a modification on a component won't break the responsiveness on the user device? How can you ensure that emails you send won't break when you change something in your UI?

What is a Visual Regression Test?

A visual regression test is a kind of test that will ensure that the result of any modification in the respective component won't break how the final user will see it.

Talking about UI components, design systems, colors, pages, emails and anything else the final user could see can be tested against visual regression.

This gives us, developers and designers, the guarantee we won't suffer from any unwanted change.

Visual Regression Testing With Jest

To have this kind of test in your codebase, you will need two libraries: jest-image-snapshot and node-html-to-image.

As the jest-image-snapshot docs says, you need to extends your expect. Here's an example how you can do it:

// jest.setup.js
import { toMatchImageSnapshot } from 'jest-image-snapshot';

expect.extend({ toMatchImageSnapshot });

After that, you can use expect().toMatchImageSnapshot() in any test of your codebase.

How we can write some kind of test that will test those snapshots? You can follow the code below:

// __tests__/Component.spec.(jsx|tsx)
import { render } from '@testing-library/react';
import htmlToImage from 'node-html-to-image';

import { Component } from '../Component';

it('match visually snapshot - or any good test message here', async () => {
  const { container } = render(<Component />);

  const image = await htmlToImage({
    html: container.innerHTML,
  });

  expect(image).toMatchImageSnapshot();
});

After all, how this works?

In this case, the toMatchImageSnapshot only accepts a JPG buffer, it's where the node-html-to-image library enters. From a HTML string, the library will output a JPG buffer that will be used as what we expected in the test.

Similar to other snapshot tests, when you run it for the first time, it will produce a new folder called __image_snapshots__, inside it will have the "snapshotted" image to be compared.

In case something goes wrong, the test will breaks and will produce a new folder, inside the __image_snapshots__, called __diff_output__. This folder will contain both the new and old images, side-by-side, that you can use to visualize the changes.

If you want to know more about how we test our UI, we are hiring!

We are a startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

You shouldn't write CSS anymore

Guilherme Ananias — Mon, 31 Oct 2022 12:00:00 +0000

If you are writing too much CSS, the design system is wrong, or you are doing something wrong, or both.

Any time you write a new rule to your CSS class or anything else, you add more noise to your code, more entropy. The next time you debug something on that code, you will need to deal with that entropy added.

Think of a team with too many developers, each developer writing your custom CSS; what could be the final result? I don't know, but the only thing I know is that the next time that someone debugs it will spend too much time on useless things trying to understand what everything does inside it.

CSS is a powerful tool for styling things in web development. You can do many things just with simple rules. In recent years, features like CSS variables, CSS at-rules like: @import and @layer, and other things have improved the edges of what you can do with this DSL.

But, as Uncle Ben said:

With great power comes great responsibility.

For a side, a thing that allows you to do the impossible inside a browser: turn simple boxes into beautiful ways to represent the limits of human creativity, it's a powerful tool. On another side, you still have a powerful tool. You need to limit what things you will do and how you will do them.

Things like BEM or OOCSS to create methodologies and patterns about how naming things, frameworks like Bootstrap or TailwindCSS, all of these things are solutions to limit what you can do based on some standards.

CSS as a piece of a puzzle

Think about your site as an enormous puzzle. Every piece is there to compound a final result: a beautiful view of your business. Everyone should talk about the same thing and follow the same patterns.

Typography elements should follow the same aspect: font size, font families, font-weight, and other related things. Color palettes should be the same on each part of your application, following a theme. You will handle spacing, like margin and padding, being the same too.

Following this philosophy, the next time you need to add any new feature to your application, you will spend too little time writing CSS because everything had done.

Furthermore, your styles should be converged into a single source of truth. If you have three places where you declare how your button works, each with its rules when you need to fix some bug in the color rule, how could you replicate it throughout your entire application? How much time will you spend trying to find what places are wrong after fixing the bug?

When you have a single source of truth, you have a win/win situation. You will spend much less time trying to find where things are; you already know it. You will ensure that everything follows what you expect while talking about your product brand.

Design systems to the rescue

A design system is just a way to structure and say what and how you can do something inside your application. It will fill some expectations like colors, typography, spacing, and other elements in general. Each of these parts, taken together, creates your application brand. And the consistency behind this matter to the final user. They will know how things work and will assimilate those things into your product.

Here, at Woovi, we follow this philosophy. Using Material UI, we ensure that every piece of our software is reusable. We focus on creating simple building blocks that can fit any place. We know that we won't need to write useless CSS.

Another helpful tool we are using here is Storybook. Every reusable component from our codebases comes from a package called UI. Inside that package, we had a .stories.tsx file that displays the respective component with its props, some examples, and other useful documentation.

If you are curious about how we manage our design system, turns it more consistent and would like to know how you could do it, we are hiring!

We are a startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

SlackOps: logging applications into a Slack channel with JavaScript

Guilherme Ananias — Sun, 09 Oct 2022 16:12:11 +0000

Here at Woovi, we manage a lot of logs of our applications in Slack channels. We can know things like:

For what reason some requests failed;
Who is the new user, the company, what is the flow that they went, etc;
Things related to Pix like if someone paid a QR code, withdrawals, some refund, etc;

We care about the data and security of all our users, therefore we sanitize and avoid sending any sensitive data.

All of it is even in our development environments too, local and staging.

How can I log things into some channels?

Here we create a simple function called sendtoSlack where we handle both @slack/node and @slack/webhook libraries internally.

So we get our webhook request URL created by Slack and put it into an environment variable like: process.env.SLACK_WEBHOOK. See here:

// .env
SLACK_WEBHOOK = 
"https://api.slack.com/messaging/webhooks/<foo>/<bar>";

You can see here how to create your webhook URL.

After you own your URL, we just create an instance from IncomingWebhook with this webhook as your url argument. For example:

import { IncomingWebhook } from '@slack/webhook'; 

const wh = new IncomingWebhook(process.env.SLACK_WEBHOOK);

Now, we just do a simple conditional validating in which environment you are and get the Slack channel based on it. Like this:

const getChannel = (channel: string) => {
  const isProduction = process.env.NODE_ENV === 'production';

  if (!isProduction) return `${channel}-dev`;

  return channel;
}

Then, you can send your message now. Using your IncomingWebhook instance, just execute the send method.

const wh = new IncomingWebhook(process.env.SLACK_WEBHOOK);

await wh.send({
  channel: getChannel('<some channel here>'),
  blocks: // your message will go here
});

And you will see your messages in your Slack channels! Now, you can abstract it to a function to use it anywhere.

The final result will be something like this:

const sendToSlack = async ({
  channel,
  blocks,
}) => {
  const getChannel = (channel: string) => {
    const isProduction = process.env.NODE_ENV === 'production';

    if (!isProduction) return `${channel}-dev`;

    return channel;
  }

  try {
    const wh = new IncomingWebhook(process.env.SLACK_WEBHOOK);

    wh.send({
      channel: getChannel(channel),
      blocks,
      // feel free to add any other arguments from this function that fits your needs.
    });
  } catch (err) {
    // do something with the error
    // here, we logged into Sentry
  }
}

With that function, you can reuse the logging anywhere on your codebase.

You can reach a similar behavior using another communication tool, like Discord or anything else. Just see how they handle webhooks or things like that.

By the way, if you are curious about what is blocks, you can see here what is the Block Kit from Slack. Is just a prettier way to log things.

If you want just simple messages, you can use attachment argument from wh.send.

You can see a simple example of how we log things using the sendToSlack function:

sendToSlack({
  channel: 'join',
  attachments: [
    {
      text: 'Invalid recaptcha attempt',
    },
    ...getSomeUsefulData(), // here we get some useful data like timestamp, etc
  ],
});

Woovi is a Startup that enables shoppers to pay as they like. To make this possible, Woovi provides instant payment solutions for merchants to accept orders.

Here we do a lot of things with Slack to improve our daily processes, if you are curious about that, we are hiring!

DMs do not scale your company

Guilherme Ananias — Sat, 08 Oct 2022 13:02:52 +0000

Your startup won't grow while your employees discuss things in direct messages. Every discussion should be public. Every piece of knowledge should be shareable with everyone inside your company.

Discuss everything in public channels

Discord, Slack, or even mailing lists, all discussions inside your company should be public. Everyone inside it should be capable of giving an opinion about the theme that was discussed if they want, and you should promote a culture where all employees have an idea about it.

Your employee should know about the following:

What other people are talking about that theme;
Why other people are talking about that theme;
What is the opinion from everyone about that theme;
What is the path and the strategy that they are taking based on what has been discussed about that theme;

Promoting a culture of learning in public

Do you know what issues your coworkers are solving? If someone asks you what the people next to you are solving, can you explain it in some detail? Do you know what progress has been made? If, for some reason, your coworker needs to stay off for some days, maybe because sick, can you take their issue and finish it in a few days, or will you need to take time to understand what was the pieces of the puzzle that your friend found?

Promoting a culture where each other knows what is going on, what is their issues and the issues of their coworkers and how and why they did some decisions is a way to turn your company more antifragile, stronger, and goes faster than your competitors.

How could I create this culture in my company?

Create an environment where everyone can ask any question and everyone can help solve the doubt; questions should be in your public channels;
Every time that doubt was solved, incentive them to create an article on your internal documentation* about the issue and how they can solve it and a blog post talking about the problem;
Promote events where everyone can interacts with each other, in some way can improve what they know about each other and improve the "general-knowledge" context about your company, codebase or anything else.

Here at Woovi, we promote a culture of shareable knowledge from each other in the company, every discussion is made on public channels and we have a internal documentation with a lot of notes about issues and other internal things, like architecture decisions, etc. We need it to move faster than our competitors.

If you think that fits into this culture and wants to work in a place like that, we are hiring!

Forem: Guilherme Ananias

How to generate dynamic OG (OpenGraph) images with Satori and React

Sharing the Payment Link

Using Satori to Generate the Image

Implementing the endpoint

Rendenring the SVG

Adding the metatag on HTML

Conclusion

Implementing Simple Paxos Consensus Algorithm With Rust

What Is Consensus?

The Simple Paxos

Preparing the proposal for a new value

Receiving the prepared value and sending the promise

Receiving the promise and handling the acceptance message

Learning the accepted value

Conclusion

Further Reading

How To Write Material UI Components Like Radix UI And Why Component Composition Matters?

Radix UI and The Composition Flow

Material UI And Radix UI, Not Enemies, But Friends

It's All About Context

Dialoguing For Us

Conclusion

How To Handle Data With GraphQL Relay Client Schema Extensions

Extending My GraphQL Schema

Managing The Data in The Store

Initializing The Local Data

Other Resources

Design System 101: Top-down Approach in Component Spacing

Bottom-up

Top-down

When margin rule can be applied?

About us

Server-side Rendering (SSR) From Scratch with React

Why Use Server-side Rendering?

Starting Server

Rendering UI

In Conclusion

About us

Blogroll: the list of blogs that I like to read

Summary

Personal blogs

Company blogs

Self-improvement

Computer science

Newsletters

RSS Feeds

Avoiding UI Regressions With Jest

What is a Visual Regression Test?

Visual Regression Testing With Jest

You shouldn't write CSS anymore

CSS as a piece of a puzzle

Design systems to the rescue

SlackOps: logging applications into a Slack channel with JavaScript

How can I log things into some channels?

DMs do not scale your company

Discuss everything in public channels

Promoting a culture of learning in public

How could I create this culture in my company?

When `margin` rule can be applied?