Forem: Atle Frenvik Sveen

Recoil atom effects

Atle Frenvik Sveen — Fri, 24 Feb 2023 07:57:36 +0000

..are effing cool!

I've been using Recoil.js for a while now, but I've never taken the time to dive into atom effects before recently.

Why did I do so? Because I needed a timer. Or a clock if you will. Running in recoil. And atom effects seems to do the trick. Just look here

import {AtomEffect, atomFamily} from 'recoil';

export type Millisecounds = number;

const getUnixNow = () => Math.floor(Date.now() / 1000);

const clockEffect =
  (interval: Millisecounds): AtomEffect<number> =>
  ({setSelf, trigger}) => {
    if (trigger === 'get') {
      setSelf(getUnixNow());
    }
    const timer = setInterval(() => setSelf(getUnixNow()), interval);
    return () => clearInterval(timer);
  };

/**
 * Atom that contains the current unix timestamp
 * Updates at the provided interval
 */
export const clockState = atomFamily<number, Millisecounds>({
  key: 'clockState',
  default: getUnixNow(),
  effects: (interval: Millisecounds) => [clockEffect(interval)],
});

This gives you an atomFamiliy that can be instantiated with the desired interval, and this atom automagically updates each interval, in this case returning the current unix timestamp

const time = useRecoilValue(clockState(1000)); //new clock state that updates every secound

return <div>The current Unix time is now: {time}</div>

Neat?

Well. But what you can do is use this as a trigger in a selector that needs to run periodically

export const pollerState = selector<SomeData[]>({
  key: 'pollerState ',
  get: async ({get}) => {
    //add this to referesh every minute
    get(clockState(60000));
    return await myApi.getSomeData();
  },
});

And this is pretty neat!

And if this doesn't get you hooked on atom effects, take a look at this, straight outta the recoil docs (Just some TypeScript added):

export const localStorageEffect =
  <T>(key: string): AtomEffect<T> =>
  ({setSelf, onSet}) => {
    const savedValue = localStorage.getItem(key);
    if (savedValue != null) {
      setSelf(JSON.parse(savedValue));
    }
    onSet((newValue, _, isReset) => {
      isReset ? localStorage.removeItem(key) : localStorage.setItem(key, JSON.stringify(newValue));
    });
  };

const syncedState = atom<string>({
  key: 'syncedState',
  default: '',
  effects: [localStorageEffect('local_storage_key')],
});

This actually syncs your atom to local storage. Sweet!

TypeScript types from lists

Atle Frenvik Sveen — Tue, 29 Nov 2022 09:25:15 +0000

I assume you know about types in TypeScript. That is kinda the essence.

And you've probably run into situations where you want to or together different things into a type. Like me, when I want to summarize beers I like, I can say:

type AtlesKindOfBeer = 'ipa' | 'stout' | 'lambic';

Whith this defined, I can create a function like this:

const serveAtleBeer = (beer: AtlesKindOfBeer) => console.log("Cheers");

This means that we avoid situations like this:

serveAtleBeer('lite banana-neipa');

But, say that you are handed a string describing a beer style, and want to check if this is a beer I like?

Typeguards to the rescue!

const isAtlesKindOfBeer = (beer: string): beer is AtlesKindOfBeer 
  => ['ipa', 'stout', 'lambic'].inludes(beer);

This works. Kinda. See the problem? Duplication! Say that I want to add "geuze" to my list of drinkable beers. Then I have to update both the AtlesKindOfBeer type and the isAtlesKindOfBeer typeguard. And here lies a potential for fuckup. And every potential for fuckup will, someday, develop into a fuckup.

So, how do we eliminate the potential? We define the list of beers I like once. Like this:

const atlesKindsOfBeer = ['ipa', 'stout', 'lambic'] as const;

then both the type and the typeguard can reference this list:

type AtlesKindOfBeer = typeof atlesKindsOfBeer[number];

const isAtlesKindOfBeer = (beer: string): beer is AtlesKindOfBeer 
  => atlesKindsOfBeer.inludes(beer as AtlesKindOfBeer);

Hooray!

Btw: the as const syntax is known as a [const assertion]!(https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions)

Recoil.js async selectors

Atle Frenvik Sveen — Fri, 18 Nov 2022 10:29:57 +0000

In the first post on Recoil.js I touched upon atom, which is a piece of state that can be read and written.

Then I followed up by showing how a selector can be used to derive state from atoms.

This is all fine. But Atle, ever since the days of XMLHttpRequest, JavaScript has been used to fetch data from APIs. And in 2022 I expect to be able to do this async!

I hear you!

And in this post I'm going to cover how to do exactly this.

Say we have this API for retrieving blog posts:

export interface BlogPostHeader {
  title: string;
  id: number;
}

export interface BlogPost extends BlogPostHeader {
  content: string;
}

export interface BlogApi {
  getPosts: () => Promise<BlogPostHeader[]>;
  getPost: (id: number) =>  Promise<BlogPost | undefined>;
}

Nice, eh? Well, good enough to serve our illustration purposes I guess.

But having an API isn't enough, we need to be able to show data, right?

So you guessed it, we need those blog posts in state. And, how do we do that?

Using a selector, of course!

And, the get method of a selector can of course be async:

const blogPostListState = selector<BlogPostHeader[]>({
  key: "blogPostListState", 
  get: async ({get}) => await api.getPosts()
});

The observant reader may ask: "where do you get the api object from?". Let's just say that for now this is a singleton, ok? Bear with me, please.

OK, we have an api, and we have this represented as a selector. How do we use it?

Using useRecoilValue of course!

But, the selector is async?

Yeah, right, we have to wrap things in a React <Suspense> block. Like so:

const BlogPostList = () => {
  const posts = useRecoilValue(blogPostListState)
  return <ul>{posts.map(post => <li key={post.id}>{post.title}</li>)}</ul>
}

export const MyBlog = () =>  (
  <>
    <h1>My awesome blog</h1>
    <Suspense fallback="loading"><BlogPostList /></Suspense>
  </>
);

Or, you could use useRecoilValueLoadable and get a loadable back. This leaves more control up to you, and can be handy in some situations. But that is a topic for another day. We'll stick with Suspense for now.

But we want the user to be able to select a specific blog post as well, right?

Yep! We could store the selected post id in an atom and call getPost in another selector. Like so:

const selectedPostState = atom<number | undefined>({
  key: "selectedPostState",
  default: undefined
});

const selectedPostContentState = selector<BlogPost | undefined>({
  key: "selectedPostContentState",
  get: async ({get}) => {
    const id = get(selectedPostState);
    return id ? await api.getPost(id) : undefined;
  }
});

And then we just have to wire this up. With some refactoring, because our components are getting rather messy:

const BlogPostListElement = ({post}: {post: BlogPostHeader}) => {
  const setSelected = useSetRecoilState(selectedPostState);
  return (
    <li onClick={() => setSelected(post.id) }>
      {post.title}
    </li>
  );
}

const BlogPostList = () => {
  const posts = useRecoilValue(blogPostListState)
  return (
    <ul>
      {posts.map(post => <BlogPostListElement key={post.id} post={post} />)}
    </ul>
  );
}

Don't you just love the misuse of list elements? Well. I never claimed I had an iota of design-capabilities. But you get the gist here. And I'm on a tangent.

To get back on track: What's going on here? When the user clicks a blog post we set the selectedPostState. So, what remains is to create a component to show the selected blog post (if any):

const BlogPostContent = () => {
  const post = useRecoilValue(selectedPostContentState);
  return post 
    ? <>
        <h2>{post.title}</h2>
        <p>{post.content}</p>
      </> 
    : null;
}

And then we have to use this component in our app, wrapped in Suspense of course:

export const MyBlog = () => (
  <>
    <h1>My awesome blog</h1>
    <Suspense fallback="loading"><BlogPostList /></Suspense>
    <Suspense fallback="loading"><BlogPostContent /></Suspense>
  </>
);

And there you have it. Bob is your fathers brother and all that.

But what is going on?

Ok, we have three pieces of state

selectedPostState: an atom containing the id of the selected post (if any)
blogPostListState: an async selector that fetches the list of blog posts. This will only be evaluated once, as it has no dependencies
selectedPostContentState: an async selector that fetches the selected blog post if set. This will re-evaulate each time selectedPostState, as it depends on it.

And each of our components interacts with the pieces of state that they need.

I find this very clean and easy to reason about, and hopefully you'll now have a better understanding of how recoil can be used to deal with async state.

The code for this is available at playcode.io, which started bitching about exceeding the free tier, so the code isn't as clean and separated as I wanted, so for the next installment I'll find another codepen. Maybe codepen? ;)

Because, yes, there will be a next installment. We have so many other topics to cover, such as

Organization of a project
selectorFamilies
error handling
testing
initializeState
Loadables
crazy chaining

And more. So, check back or subscribe or whatever ;)

Recoil.js

Atle Frenvik Sveen — Thu, 17 Nov 2022 10:40:15 +0000

Redux is pretty awesome. Well, the idea behind redux is pretty awesome (go ahead and read Human Redux, it's great!). But the implementation, and React-integration, leads to lots of files, biolerplate and hassle [personal opinion, feel free to disagree].

So, when something new¹ comes along that promises to solve those issues, it has to be explored. And so I did, a year ago or something. Recoil.js brands itself as “A state management library for React” that is “Minimal and Reactish”.

Sounds good? I was sceptical, but after using it for about a year I very much like what I see. My main gripe with it is perhaps a certain lack of excamples, so to alleviate that some examples might be what’s called for.

So, why recoil?

Well, for a starter, consider this component

import React, {useState} from 'react';

export const MyCounter = () => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <div>Count: {count}</div>
      <button onClick={() => setCount((count) => count + 1)}>Increment</button>
    </div>
  );
};

A bog-standard, boring, counter.

But, now we want to refactor this and split it into a button-component and a display component

import React, {useState} from 'react';

interface MyCounterButtonProps {
  increment: () => void;
}
const MyCounterButton = ({increment}: MyCounterButtonProps) => 
  <button onClick={() => increment()}>Increment</button>;

interface MyCounterDisplayProps {
  value: number;
}
const MyCounterDisplay = ({value}: MyCounterDisplayProps) => 
  <div>Count: {value}</div>;

export const MyCounter = () => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <MyCounterDisplay value={count} />
      <MyCounterButton increment={() => setCount((count) => count + 1)} />
    </div>
  );
};

Well, this works. But we have to pass props, and these components are coupled. Surely there is a better way?

This is where recoil comes into play, if we use an atom:

import React from 'react';
import {atom, useRecoilValue, useSetRecoilState} from 'recoil';

const counterState = atom<number>({
  key: 'counterState',
  default: 0,
});

const MyCounterButton = () => {
  const setCounter = useSetRecoilState(counterState);
  return <button onClick={() => setCounter((count) => count + 1)}>Increment</button>;
};

const MyCounterDisplay = () => {
  const value = useRecoilValue(counterState);
  return <div>Count: {value}</div>;
};

export const MyCounter = () => (
  <div>
    <MyCounterDisplay />
    <MyCounterButton />
  </div>
);

See how we moved the state from the MyCounter component? Instead we put it into an atom, which we can access using the useRecoilValue hook, and set using the useSetRecoilState hook.

This allows us to share state between components without passing it as props. Big deal? Well, not in this case perhaps, but we avoid long prop chains, and we are able to share state between components that are far apart from each other in the component tree.

But, wait, is recoil just useState on streoids?

No, by no means! Recoil is a fully-fledged state managemnent library, with support for async queries and reducers. But we have to start somewhere!

This post is already getting long though, so we'll just cover one (simple) example of derived state.

Say we wanted our counter to display a message when the count was an even number.

Easy:

const IsEvenDisplay = () => {
  const value = useRecoilValue(counterState);
  return <div>{value % 2 == 0 ? "even!": null}</div>;
}

This is of course really trivial, but say we had a more complex computation, that was unnatural to compute in a component.

Then we could use a recoil selector, and compute it there:

const isCounterEvenState = selector<boolean>({
  key: "isCounterEvenState",
  get: ({get}) => get(counterState) % 2 === 0
});

const IsEvenDisplay = () => {
  const isCounterEven = useRecoilValue(isCounterEvenState);
  return <div>{isCounterEven ? "even!": null}</div>;
}

Clean, eh?

And of course, there are lots of other aspects to recoil. How do we handle async queries? How do we test this? How do we organize things?

Those are all interesting subjects that we'll touch upon in a later installment.

For now: If you haven't played around with recoil I strongly recommend that you do. The examples shown here are available at the first, half-decent, codepen-lookalike I could find: here.

Installments in this series:

Recoil.js (this post)
Recoil.js async selectors

"New" is a very relative term. ↩