DEV Community: Guilherme Oderdenge

Virtualize your grids with React and Virtualform

Guilherme Oderdenge — Mon, 28 Nov 2022 16:31:19 +0000

When you have a grid of an unknown amount of cells, it's a good idea to virtualize it, specially if you expect that grid to display a great amount of data.

Take your phone's photo gallery as an example: it renders hundreds of thousands of photos without a sweat, and that's mostly only possible because of virtualization (sometimes referred to as 'windowing').

In a nutshell, virtualization — or windowing — is a technique of "unloading" things that aren't visible to the user (because these things are supposed to be needless at that moment) thus making your application perform better.

I won't dive deep into what virtualization is in this post; rather, I'd like to introduce you to Virtualform: an ultra-fast, responsive and headless virtualization engine I built for React.

Long story short, at Starchive, we were in need of a sophisticated way to virtualize our grids. The solutions out there were good, but we always felt that something was missing—which led us to build Virtualform, a solution that we love and satisfies all our needs, from the user experience to the bundle footprint.

To give you a glimpse of what @virtualform/grid looks like:

import { useGrid } from '@virtualform/grid'

const App = () => {
  const { getRootProps, getWrapperProps, cells } = useGrid({
    cells: {
      amount: 1000,
      width: 100,
      height: 100,
    },
  })

  const { style, ...rootProps } = getRootProps()

  return (
    <div style={{ ...style, width: '100vw', height: 600 }} {...rootProps}>
      <div {...getWrapperProps()}>
        {cells.map((cell) => {
          return (
            <div {...cell.getProps()}>
              <div>I am cell {cell.index}</div>
            </div>
          )
        })}
      </div>
    </div>
  )
}

Want to learn more? Read the docs and become a virtualization ninja! 🥷

Use superstate instead of React.Context

Guilherme Oderdenge — Fri, 22 Jul 2022 19:41:23 +0000

Greetings, developers!

One highly popular way developers use to share state across components is through the React's Context API, and we can't deny it is useful and have been solving our problems for quite some time.

But let's take some time to pay attention to their own documentation:

Before you use Context

Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult.

According to my perception however, one part that was completely skipped is the last one:

Apply it sparingly because it makes component reuse more difficult.

I've seen many projects—mine included—heavily relying on Context to share state. And that caused many problems; from developer experience decay to unmaintanable state management.

Just to name one problem, and very likely the most common one to me, what if you need to access a given state outside the React realm? Solving that isn't exactly straightforward and even creating a workaround solution is counterintuitive.

Let's pick another piece of what Context's docs itself says:

[...] when some data needs to be accessible by many components at different nesting levels.

Nesting is another point you have to worry about when using Context. In a large codebase, it's easy to get lost and not knowing why your state is not accurate—perhaps you're calling a Context at a level it isn't available; who knows?

These are some of the reasons why superstate exists. To make state management plain and crystal clear.

In practice

Using Context, in an app that has a dark/light theme, this is one way to achieve it:

import { createContext, useContext } from 'react'

export const ThemeContext = createContext({
  theme: 'light',
  setTheme: () => {}
})

export function App() {
  const [theme, setTheme] = useState('light')

  return (
    <ThemeContext.Provider
      value={{
        theme,
        setTheme: (newTheme) => setTheme(newTheme)
      }}
    >
      <Button />
    </ThemeContext.Provider>
  )
}

function Button() {
  const themeCtx = useContext(UserContext);  

  return (
    <button
      onClick={() => {
        themeCtx.setTheme(themeCtx.theme === 'dark' ? 'light' : ' dark')
      }}
    >
      Toggle theme
    </button>
  )
}

Now, with superstate:

import { superstate } from '@superstate/core'
import { useSuperState } from '@superstate/core'

export const theme = superstate('light')

export function App() {
  return <Button />
}

function Button() {
  useSuperState(theme)

  return (
    <button
      onClick={() => {
        theme.set(prev => prev === 'dark' ? 'light' : 'dark')
      }}
    >
      Toggle theme
    </button>
  )
}

Conclusion

As you can see from the example above, superstate has trimmed down the code required to achieve the same solution. That's not the pivotal point though; the graceful part is that you have a sleeker, more welcoming API that doesn't care about hierarchy or nesting, leading to a cleaner code and greater developer wellness all around. Also, have you noticed you didn't have to create a set method yourself? 🪄

That said, maybe in your next state it'd be worth considering superstate as an option for state management? I'm pretty sure you're going to like it.

Creating a global notifications system with superstate and React

Guilherme Oderdenge — Wed, 20 Jul 2022 19:11:49 +0000

Greetings, developers!

I'd like to show you my take on how to build a simple global notifications system with superstate and React.

We have one extra, implicit goal: building something with satisfying ergonomics and developer experience.

With no further ado,

If you prefer, there's also a video of this guide available!

Prerequisites

I'm going to create a brand new create-react-app application with TypeScript:

yarn create react-app superstate-notifications --template typescript

Note that I am using yarn, but you can mimic my commands using npm as well.

Once it's done, let's move our working directory to the superstate-notifications application we just created:

cd superstate-notifications

And then let's install superstate:

yarn add @superstate/core

Cool. Now we have a project that's good to go.

What is superstate?

In short, superstate is a micro state management library for JavaScript applications. Despite the nuances, you can think of it as an alternative solution for Redux or Zustand.

It was designed with developer wellness in mind, and comes bundled with a powerful and handy drafts system to make our lives easier and less repetitive.

Getting started

Now that you have a working project to get your hands dirty, let's create a notifications.tsx file within src/ and bootstrap the state of our notifications:

import { superstate } from '@superstate/core'

const notifications = superstate([])

Note the [] within superstate(). That's the initial value of your state. It's as if you'd have typed:

const notifications = []

Except that you wrapped the empty array inside a superstate, and that gives us powers.

Creating & destroying notifications

The next step is creating the two most important functions of the notifications feature: notify and destroy. Respectively, one is meant to issue new notifications and the other is to destroy them.

This is what I came up with:

function notify(message: string) {
  const id = Math.random().toString()

  notifications.set((prev) => [...prev, { id, message }])
}

function destroy(id: string) {
  notifications.set((prev) => prev.filter((p) => p.id !== id))
}

The `notify` function

It expects to receive a message (of type string) argument. This message is what the user is going to see once the notification pops up.

Also, this function declares an id variable and assigns Math.random().toString() to it. This is just because we want our system to support multiple notifications at once, and we must have a way to differentiate one notification from another—id is the way.

Furthermore, the notify function calls .set() from our notifications object. If you scroll up a little, you're going to notice this notifications object is our superstate() variable, thus .set() is a function returned from it.

It may look complicated at first, but all we're doing is passing to .set() a function that returns what the list of notifications should look like once we emit this new one.

prev is the previous value of notifications. Initially, the value of notifications is [] (an empty array), but as we start emitting notifications, this array will eventually grow—so prev ensures that we're adding new notifications instead of replacing them.

Look at what we are doing again:

notifications.set((prev) => [...prev, { id, message }])

It means the next value of notifications is the former notifications plus the new one, which is represented by an object with the id and message properties.

The `destroy` function

Here we are telling that the next value of notifications is all notifications but the one that matches the specified id passed through the argument of the destroy function:

notifications.set((prev) => prev.filter((p) => p.id !== id))

Rendering notifications

Now in this same notifications.tsx file, let's create a Notifications Renderer. Its job is critical: displaying the notifications to the user.

Here's the bootstrap of it:

export function NotificationsRenderer() {
  useSuperState(notifications)

  return null
}

Wait, what? Where is this useSuperState() function coming from?

Yeah, I did not mention it so far. Intentionally. In order to integrate superstate with React, you have to install an extra dependency:

yarn add @superstate/react

And import it in your notifications.tsx file:

import { useSuperState } from '@superstate/react'

The useSuperState hook re-renders our component (NotificationsRenderer) every time the state passed to it changes. In our context, this "state passed to it" refers to notifications.

This is what I came up with to make the renderer fully functional:

export function NotificationsRenderer() {
  useSuperState(notifications)

  if (!notifications.now().length) {
    return null
  }

  return (
    <div>
      {notifications.now().map((n) => {
        return (
          <div key={n.id}>
            <p>{n.message}</p>

            <button onClick={() => destroy(n.id)}>
              Destroy
            </button>
          </div>
        )
      })}
    </div>
  )
}

Let's break it down:

if (!notifications.now().length) {
  return null
}

The if above guarantees that nothing will be rendered when no notifications exist. Note the now() method—it returns the current value of your notifications array. The condition states that if there are no items in the notifications list, then we'd like to render null.

{notifications.now().map((n) => {

The line above will iterate over each item in the notifications array and return something. In our context, for each notification, something will be rendered. Note that now() is present again.

return (
  <div key={n.id}>
    <p>{n.message}</p>

    <button onClick={() => destroy(n.id)}>
      Destroy
    </button>
  </div>
)

The lines above refer to the actual notification item that will be rendered in the browser and displayed to the user.

As of the last piece of the rendering puzzle, let's open ./src/App.tsx and clear the returned component to look something like this:

export default function App() {
  return ()
}

With the house clean, we can now render our renderer:

import { NotificationsRenderer } from './notifications'

export default function App() {
  return (
    <div>
      <NotificationsRenderer />

      <button>Give me a notification!</button>
    </div>
  )
}

Emitting notifications

You may have noticed we created a Give me a notification! button at the above post section but have done nothing with it. Well, yet.

Let's make it give us a notification whenever it is clicked:

<button onClick={() => notify('Hello world!')}>
  Give me a notification!
</button>

The notify function won't work right away. We first have to export it. Go back to notifications.tsx and export both notify and destroy functions by prepending the export keyword in front of the function keyword:

export function notify(message: string) {
  const id = Math.random().toString()

  notifications.set((prev) => [...prev, { id, message }])
}

export function destroy(id: string) {
  notifications.set((prev) => prev.filter((p) => p.id !== id))
}

Now, at App.tsx, you'll be able to import them:

import {
  notify,
  destroy,
  NotificationsRenderer,
} from './notifications'

And boom! Save all your files and go to your browser to play with your fresh notifications system. :)

Wrapping up

Your final notifications.tsx should look like this:

import { superstate } from '@superstate/core'
import { useSuperState } from '@superstate/react'

const notifications = superstate([])

export function notify(message: string) {
  const id = Math.random().toString()

  notifications.set((prev) => [...prev, { id, message }])
}

export function destroy(id: string) {
  notifications.set((prev) => prev.filter((p) => p.id !== id))
}

export function NotificationsRenderer() {
  useSuperState(notifications)

  if (!notifications.now().length) {
    return null
  }

  return (
    <div>
      {notifications.now().map((n) => {
        return (
          <div key={n.id}>
            <p>{n.message}</p>

            <button onClick={() => destroy(n.id)}>
              Destroy
            </button>
          </div>
        )
      })}
    </div>
  )
}

And your App.tsx:

import {
  notify,
  destroy,
  NotificationsRenderer,
} from './notifications'

export default function App() {
  return (
    <div>
      <NotificationsRenderer />

      <button onClick={() => notify('Hello world!')}>
        Give me a notification!
      </button>
    </div>
  )
}

You can see a slightly fancier example on StackBlitz:

Final thoughts

This is a pretty basic notifications system, but quite powerful and intuitive. Now, to dispatch notifications in your app, all you have to do is calling the notify() function you created yourself from anywhere in your app, including non-React code, and have fun because things will just work.

Now you go have some fun and don't hesitate to reach out with any questions or feedback! d(^_^)z

Creating a global notifications system with superstate and React

Guilherme Oderdenge — Tue, 21 Jun 2022 22:52:49 +0000

Greetings, developers!

I'd like to show you my take on how to build a simple global notifications system with superstate and React.

We have one extra, implicit goal: building something with satisfying ergonomics and developer experience.

With no further ado, shall we?

If you prefer, there's also a video of this guide available!

Prerequisites

I'm going to create a brand new create-react-app application with TypeScript:

yarn create react-app superstate-notifications --template typescript

Note that I am using yarn, but you can mimic my commands using npm as well.

Once it's done, let's move our working directory to the superstate-notifications application we just created:

cd superstate-notifications

And then let's install superstate:

yarn add @superstate/core

Cool. Now we have a project that's good to go.

What is superstate?

In short, superstate is a micro state management library for JavaScript applications. Despite the nuances, you can think of it as an alternative solution for Redux or Zustand.

It was designed with developer wellness in mind, and comes bundled with a powerful and handy drafts system to make our lives easier and less repetitive.

Getting started

Now that you have a working project to get your hands dirty, let's create a notifications.tsx file within src/ and bootstrap the state of our notifications:

import { superstate } from '@superstate/core'

const notifications = superstate([])

Note the [] within superstate(). That's the initial value of your state. It's as if you'd have typed:

const notifications = []

Except that you wrapped the empty array inside a superstate, and that gives us powers.

Creating & destroying notifications

This is what I came up with:

function notify(message: string) {
  const id = Math.random().toString()

  notifications.set((prev) => [...prev, { id, message }])
}

function destroy(id: string) {
  notifications.set((prev) => prev.filter((p) => p.id !== id))
}

The `notify` function

It expects to receive a message (of type string) argument. This message is what the user is going to see once the notification pops up.

It may look complicated at first, but all we're doing is passing to .set() a function that returns what the list of notifications should look like once we emit this new one.

Look at what we are doing again:

notifications.set((prev) => [...prev, { id, message }])

It means the next value of notifications is the former notifications plus the new one, which is represented by an object with the id and message properties.

The `destroy` function

Here we are telling that the next value of notifications is all notifications but the one that matches the specified id passed through the argument of the destroy function:

notifications.set((prev) => prev.filter((p) => p.id !== id))

Rendering notifications

Now in this same notifications.tsx file, let's create a Notifications Renderer. Its job is critical: displaying the notifications to the user.

Here's the bootstrap of it:

export function NotificationsRenderer() {
  useSuperState(notifications)

  return null
}

Wait, what? Where is this useSuperState() function coming from?

Yeah, I did not mention it so far. Intentionally. In order to integrate superstate with React, you have to install an extra dependency:

yarn add @superstate/react

And import it in your notifications.tsx file:

import { useSuperState } from '@superstate/react'

The useSuperState hook re-renders our component (NotificationsRenderer) every time the state passed to it changes. In our context, this "state passed to it" refers to notifications.

This is what I came up with to make the renderer fully functional:

export function NotificationsRenderer() {
  useSuperState(notifications)

  if (!notifications.now().length) {
    return null
  }

  return (
    <div>
      {notifications.now().map((n) => {
        return (
          <div key={n.id}>
            <p>{n.message}</p>

            <button onClick={() => destroy(n.id)}>
              Destroy
            </button>
          </div>
        )
      })}
    </div>
  )
}

Let's break it down:

if (!notifications.now().length) {
  return null
}

{notifications.now().map((n) => {

The line above will iterate over each item in the notifications array and return something. In our context, for each notification, something will be rendered. Note that now() is present again.

return (
  <div key={n.id}>
    <p>{n.message}</p>

    <button onClick={() => destroy(n.id)}>
      Destroy
    </button>
  </div>
)

The lines above refer to the actual notification item that will be rendered in the browser and displayed to the user.

As of the last piece of the rendering puzzle, let's open ./src/App.tsx and clear the returned component to look something like this:

export default function App() {
  return ()
}

With the house clean, we can now render our renderer:

import { NotificationsRenderer } from './notifications'

export default function App() {
  return (
    <div>
      <NotificationsRenderer />

      <button>Give me a notification!</button>
    </div>
  )
}

Emitting notifications

You may have noticed we created a Give me a notification! button at the above post section but have done nothing with it. Well, yet.

Let's make it give us a notification whenever it is clicked:

<button onClick={() => notify('Hello world!')}>
  Give me a notification!
</button>

export function notify(message: string) {
  const id = Math.random().toString()

  notifications.set((prev) => [...prev, { id, message }])
}

export function destroy(id: string) {
  notifications.set((prev) => prev.filter((p) => p.id !== id))
}

Now, at App.tsx, you'll be able to import them:

import {
  notify,
  destroy,
  NotificationsRenderer,
} from './notifications'

And boom! Save all your files and go to your browser to play with your fresh notifications system. :)

Wrapping up

Your final notifications.tsx should look like this:

import { superstate } from '@superstate/core'
import { useSuperState } from '@superstate/react'

const notifications = superstate([])

export function notify(message: string) {
  const id = Math.random().toString()

  notifications.set((prev) => [...prev, { id, message }])
}

export function destroy(id: string) {
  notifications.set((prev) => prev.filter((p) => p.id !== id))
}

export function NotificationsRenderer() {
  useSuperState(notifications)

  if (!notifications.now().length) {
    return null
  }

  return (
    <div>
      {notifications.now().map((n) => {
        return (
          <div key={n.id}>
            <p>{n.message}</p>

            <button onClick={() => destroy(n.id)}>
              Destroy
            </button>
          </div>
        )
      })}
    </div>
  )
}

And your App.tsx:

import {
  notify,
  destroy,
  NotificationsRenderer,
} from './notifications'

export default function App() {
  return (
    <div>
      <NotificationsRenderer />

      <button onClick={() => notify('Hello world!')}>
        Give me a notification!
      </button>
    </div>
  )
}

You can see a slightly fancier example on StackBlitz:

Final thoughts

Now you go have some fun and don't hesitate to reach out with any questions or feedback! d(^_^)z

Questioning GraphQL's Fragments

Guilherme Oderdenge — Thu, 09 Apr 2020 19:49:03 +0000

I dare to say that 70% of my career I spent living together with REST, but barely can remember of it and its good practices. I remember we had standards; I remember we had routes; I remember there was a distinction between REST and RESTful. The most iconic thing I remember is that we had requests returning huge amounts of fields and the major part of those were oftentimes needless. Then GraphQL came around.

I bluntly fell in love at the first stare it gave me. What a time to be alive, huh?

Thing is, as someone who worked in a daily basis with REST, doing the migration was not seamless. New concepts, several different new keywords, good practices peeking around the corner. It was not only a new MVC framework—it was a whole different and modern mentality.

Back then, before getting my hands dirty, I spent hours reading and skimming articles. Queries, mutations, fragments, resolvers, etc. When I felt I was too confused, just gave up with the formal education and picked Relay's "Quick" Start guide to see the thing in practice.

So I started learning GraphQL in the front-end. Mostly, what we had there—and still have—were Queries and Mutations. These two—specially Queries—were easy to tame. However, one thing I skipped completely was Fragments. The truth is that was naive from me doing so because, nowadays, it's clear it is a core mechanism the technology has to offer.

There is one fundamental piece on my naiveness: I started working with GraphQL in a daily basis and meanwhile skipping and ignoring Fragments the entire time. Back to my first reading on GraphQL, I skipped Fragments because "oh, alright, I'll check it out later", but this "later" ended up meaning years.

Year is 2019. Now with some experience in GraphQL, I decided to create a "serious" pet project, and those who, like me, fantasise serious pet projects, they go wild when it comes to programming seriousness. I'm serious.

Picture this: a developer in front of his computer running yarn add non-stop, setting up all the foundation for his next big venture. I mean, pursuing the codebase that would make Facebook envy. C'mon, who never?

Anyways, time to get even more serious about GraphQL and expand my knowledge further.

Sat down in my computer and spent hours on some serious (lol), deep reading. This time no skim. Suddenly, I got to it: Fragments. I remember it was an Apollo page (maybe this one).

Cool, you can easily reuse pieces of your Queries out and about
— My younger self thought

Before reading that page and diving deep into it, what I imagined about Fragments is that its function would go beyond merely serving as variables to hold fields one want to use in different Queries. Hence I imagined it was a way to reuse the values of those fields that were returned from the data of a real query. In other words, I fantasised that Fragments was a kind of cache.

But then, after the reading I mentioned earlier, the quote of myself above became my new axiom. It's literally just a DRY; developer sugar. And please, don't get me wrong—that's not bad at all.

Turns out that when I realised that, frustration and relief occurred to me at the same time. Frustration because my imagination was completely wrong; relief because I could achieve GraphQL without Fragments.

Bringing the climax to the table, in this serious project of mine, I experimented Fragments a little bit. At first, I felt the productivity at my fingertips and thought how I survived all this time without it, however it didn't take long to show up some bleedings.

To give you some easy-to-digest examples, these are a few things that happened to me:

Different Fragments for the same fields;
The need to open the file the Fragment was to confer its fields (slowing me down);
The need to search within my codebase to check if a Fragment for a given batch of fields already existed.

That started to piss me off. My loss on productivity was concrete, I could more than see it; I could feel it.

The cherry on the cake was that Fragments made me feel I was doing wrong GraphQL. Not technically, but theoretically.

It's easy to agree that the greatest achievement of GraphQL, at least compared to REST, is that it allows you to explicitly request exactly what you want when performing a request. You don't GET /users and just accept whatever the response gives you. You are free to nitpick only the fields that make sense to that specific situation.

So let's take this example from the official GraphQL documentation:

{
  leftComparison: hero(episode: EMPIRE) {
    ...comparisonFields
  }
  rightComparison: hero(episode: JEDI) {
    ...comparisonFields
  }
}

fragment comparisonFields on Character {
  name
  appearsIn
  friends {
    name
  }
}

This seems to be the perfect use case for Fragments. And, in fact, it is. But reality isn't always that kind with us. Because, for some reason, the PO wants the leftComparison and only the leftComparison to show something like the "flag" of the hero.

In your day-to-day, with lots of tasks piled in your backlog, one natural and quick fix for that would be doing this:

fragment comparisonFields on Character {
  name
  appearsIn
  flag # here
  friends {
    name
  }
}

And boom! You can now access data.leftComparison.flag and do whatever you want with it.

However, this "quick fix", which I doubt that would be something rare for one to do, comes at a cost: we are also retrieving flag to the rightComparison, and that particular hero doesn't need it. Of course, flag might be cheap to query and may not bother the bandwidth of your customers and users, but it definitely breaks the most fundamental principle of GraphQL that is just ask for what you need.

This also happened to me. I was using some Fragments to share common fields and in these queries I implemented them were oftentimes requesting unneeded stuff.

The ironic conclusion I took about this situation is that GraphQL has a functionality prone to diverge from itself. Fragments seems to me an innocent, induced solution to avoid repetition brought by the Facebook team, capable of sneakily implode an anti-pattern in our requests, codebase and whatnot; I feel that those unsuspecting, unaware programmers could easily get caught on doing REST through GraphQL without any acknowledgement or consciousness.

To overcome my problems then, I left Fragments behind and started CTRL+Cing and CTRL+Ving instead. Pure redundancy and repeating myself. Cheap solution. Explicit versus implicit. One less abstraction and needless complexity to worry about.

But I want to state a few things before wrapping up. Starting with the fact that I'm not saying don't use Fragments or Fragments is crap, please Facebook remove it from GraphQL.

I'm saying that I have the impression it can be harmful depending on how you use it, where harmful might mean flag could be an expensive field to query for; or harmful might mean it could damage your developer experience, slowing you down.

Secondly, I haven't used Fragments for long, nor in massive scale projects. That said, perhaps I could have misunderstood it or may be lacking the ideal experience to make it profit. Or maybe I'm simply using it wrong. Worth to mention I really tried. And I really wanted to use it the right way.

Thirdly, Fragments do you any good? Alright, go for it! It's there to be used.

Now, don't be shy—share your thoughts. Have you had a bad experience with Fragments as well? Or a good one? The microphone is all yours.

Peace.

DEV Community: Guilherme Oderdenge

Virtualize your grids with React and Virtualform

Use superstate instead of React.Context

Before you use Context

In practice

Conclusion

Creating a global notifications system with superstate and React

Prerequisites

What is superstate?

Getting started

Creating & destroying notifications

The notify function

The destroy function

Rendering notifications

Emitting notifications

Wrapping up

Final thoughts

Creating a global notifications system with superstate and React

Prerequisites

What is superstate?

Getting started

Creating & destroying notifications

The notify function

The destroy function

Rendering notifications

Emitting notifications

Wrapping up

Final thoughts

Questioning GraphQL's Fragments

The `notify` function

The `destroy` function

The `notify` function

The `destroy` function