Thomas Reggi's Profile Image

@thomasreggi 🌸

What No Meta-Framework Does: Part 2

December 22, 2022 (Syndicated From

I’ve complained about meta-frameworks in the past, specifically in regards to file-system routing. But I want to explore another use case specific to my ideas for a “Widget” Site..

If I wanted to have a component, say <Customer>, and a route /customer, and I wanted both to be able to accept an id, like <Customer id={1}> and /customer/1, how could I achieve this in one definition? It seems like a simple ask, right? There are still many questions to ask. If this component is rendered on the client, should it fetch an endpoint /api/customer.json?id=1? If it were to be rendered on the server, can it not make that call? I was just exploring the idea behind “Full Stack Components” from Kent C. Dodds and I’m not quite sure it has the versatility I’m looking for. The complexity for me comes when you need a component to know about a static resource url. Normally with file system routing, this isn’t really necessary. An exported function runs server-side, like Next.js’s getServerSideProps or Remix’s loader for that route, and renders the markup.

The things I’m looking for in a route/component definition are the following:

  1. The component endpoints for loading data and input actions should be publicly exposed.
  2. The component itself should be internally reusable the same way you’d use it in a request.
  3. The component should be able to be used on the front-end and make a fetch call if desired.

Currently, it seems that most meta-frameworks do maybe one of these things.