RFC: Table Resolvers

[lucasaarcoverde]

Problem

The table resolvers were created to help the implementation of a column component and to serve as a shortcut for repetitive and direct usage of table columns. For example, you can only reuse the date resolver every time you need it, instead of implementing it many times with the column and loading logic. You can also use the root resolver to implement anything you want while reusing the resolvers logic.

This brought some questions:

• When to create resolvers?
• Are resolvers a good Pattern?
• Should we have resolvers for everything?
• Should they cover 100% of the scenarios?

Why this matters?

Since when we introduced resolvers for our users we don’t have defined what it is. This brings some confusion to the users and us because we don’t know when to implement a new resolver and what is the boundary of evolving a resolver.

Proposal

IMO resolvers are important and they should exist, because it saves time when implementing a table. The main pain point is the lack of documentation on how to use the resolvers, what their responsibility is, and what it isn’t.

• We should review the existing resolvers to improve their APIs
• We should document what a resolver is and how to use it
• I see people avoiding using the root resolver and using other resolvers with the render property

Resolver structure

IMO having the render prop on each resolver makes the root resolver useless, so we should remove it.

// BEFORE
interface Resolver {
  // { resolver specific properties }
  type: {resolverType},
  render?: (props: ResolverRenderProps<string, T>) => ReactNode
}

// AFTER
interface Resolver {
  // { resolver specific properties }
  type: {resolverType},
}

Resolver creation

• Every new resolver should have an RFC with an API proposal and we must avoid creating a resolver to solve a single issue
• We should reinforce the usage of the root resolver and its proposal

Pros

• Resolvers bring UI consistency since you will reuse the same logic and implementation for different projects that use the same component.
• It is easy to reuse existing patterns

Cons

• Resolvers don’t cover 100% of scenarios, sometimes they can be limiting
• The implementation of a component is by using a resolver and not in the straight React way

Unresolved questions

• Is the createColumns the best way of using resolvers?

What's next

• Menu resolver RFC proposal
• Review existing resolvers
• Remove the render property from each resolver
• Document what a resolver is and how to use it
• Document the root resolver and reinforce its usage

[anitavincent]

I think the discussion about createColumns matters a lot for deciding on how we'll use resolvers in general, so maybe we should take a step back and discuss that?

About the resolvers I personally prefer the "component" API, instead of json. That would probably be the opposite direction from what you suggested, having all resolvers "agnostic" and using the components inside the render prop... Although I'm unsure if that could be less performant somehow

[matheusps]

We don't use these resolves anymore on our table sine we adopted tanstack/table/