Why slices?

[Gregoor]

Heya, thank you for all your work on Waku! I have not used it myself yet, but I am grateful there exists a less-Vercel-y alternative, and I'm looking forward to giving it a shot in my next server-y side project.

Reading the docs, I was excited to discover a new building block: Slices! Unfortunately I could not quite make sense of them yet (despite also scouring github and the announcement blog post). I'm probably not the brightest sandwich in the drawer but I bet if I'm confused, an average reader might be too.

Let's look at the docs

Slices are reusable components that are defined in the src/pages/_slices directory. They allow you to compose pages by assembling components like normal React components while specifying alternate rendering patterns.

Up to the last three words it sounds like you're just talking about regular old components. But okay, alternative rendering patterns, interesting, what might those be?

Each slice file exports a default React component and a getConfig function that specifies the render method.

// ./src/pages/_slices/one.tsx

// Create slice component
export default function SliceOne() {
  return <p>🍕</p>;
}

export const getConfig = () => {
  return {
    render: 'static', // default is 'static'
  };
};

Ah, so my reading: if they are static, which they are by default, they will be rendered only once even if I use them multiple times?
Let's read on...

Lazy slices allow components to be requested independently from the page they are used on, similar to Astro's server islands feature. This is useful for components that will be dynamically rendered on otherwise static pages.

How is that different from a server component (a static page) that embeds a client component (an island)?

So with the only use case I'm understanding from the doc, it looks to me like a more unwieldy version of Next's use cache. But I feel like I might be missing something?

Thanks for reading!

[tylersayshi]

So to add some context it might help to mention some prior art that inspired waku slices:

• gatsby slices
• astro islands

waku slices could reductively put as an RSC implementation of astro islands or gatsby slices. (though this loses nuance)

---

Ah, so my reading: if they are static, which they are by default, they will be rendered only once even if I use them multiple times?

Static by default, but it's important that dynamic is also possible here. There are unstable api's for refetching dynamic id's, which is part of the motivation for a feature like slices.

How is that different from a server component (a static page) that embeds a client component (an island)?

Slices can be thought of as a way to further weave in RSC. For example, let's say you have a component that would benefit from being static, but you'd like to use it on multiple pages... these pages could be static or dynamic, so it makes sense to keep that component static as a slice, and the pages can still have their own choice of dynamic vs static.

So with the only use case I'm understanding from the doc, it looks to me like a more unwieldy version of Next's use cache. But I feel like I might be missing something?

I'm not the most versed on 'use cache' and believe that slices differs meaningfully, though yes theres some overlap in use cases probably. One thing we have worked to avoid is compiler tooling in waku and since 'use cache' is a novel directive (not within the scope of react itself), it didn't make sense here.