Support for standard schema on hooks like useList

[JuicyBenjamin]

I'm not entirely sure how this implementation would look like, but I do think it would be cool if I could just pass a schema and the hook automatically spits out the data as usual, but now validated against the schema and typed without having to pass a type generic.

My reasoning is this, generics are nice, as long as they are correct, but we don't really have a way to validate that isn't very cumbersome. Currently I imagine that if I wanted validation it would have to be done after the fact on each implementation.

I think we could hit two birds with one stone here and somehow accept the name of the resource through the passed schema, that way we kinda get type safety on the resource as well.

Hope this makes sense. Lemme know if you like the idea if you'd like me to contribute to the implementation :D

[CarlosOliveira-23]

Great idea, and the timing is good for this!
What you're describing maps naturally onto the Standard Schema specification — a ~60-line TypeScript interface co-authored by the creators of Zod, Valibot, and ArkType. Libraries that implement it expose a ~standard property, which means a single consumer implementation can accept schemas from any compliant library without needing per-library adapters.
A rough sketch of what this could look like on useList:
`import { z } from "zod";
import type { StandardSchemaV1 } from "@standard-schema/spec";

const PostSchema = z.object({
id: z.number(),
title: z.string(),
status: z.enum(["draft", "published"]),
});

const { data } = useList({ schema: PostSchema, resource: "posts" });
// data is typed as Post[] — no generic needed`

Under the hood, refine could call schema["~standard"].validate(record) on each item and either throw/warn on validation failure or strip unknown keys, depending on a configurable onValidationError option.
Two birds with one stone (as you said): if refine lets the schema carry the resource name via a .resource("posts") chaining method or a wrapper, you get both runtime validation and a type-safe resource binding. That said, keeping resource as an explicit prop might be safer to avoid coupling schema libraries to refine's domain model.
Prior art: TanStack Form and tRPC already consume Standard Schema this way — integrate once, support all compliant libraries. Refine adopting the same interface would be a natural fit given its provider-agnostic philosophy.
Happy to help sketch out a PR if the maintainers are open to it — the core change would likely live in @refinedev/core around the useList/useOne/useMany data hooks.

[JuicyBenjamin]

Yup that is pretty close to what I was thinking. We could attempt with opening a PR, but I've heard that refine have essentially entered maintenance mode on core, cutting head count and focusing on their AI product, so I unfortunately think it would die in the water. Although I would really like this change

[CarlosOliveira-23]

That's a fair concern — if the core team is in maintenance mode, a PR might not get reviewed anytime soon. That said, it might still be worth opening it as a draft PR or a RFC (Request for Comments) just to gauge official interest. Sometimes maintainers will fast-track small, well-scoped changes even in maintenance mode, especially if it reduces their own support burden (no more per-library adapter requests).
Alternatively, this could live as a community plugin or wrapper outside of @refinedev/core entirely — something like @refinedev/standard-schema that wraps useList/useOne with Standard Schema support without touching core. Lower risk, no need for maintainer bandwidth.
Either way, happy to collaborate on either path if you decide to move forward!