Virtual resolver properties

The problem

Currently, there is no differentiation between resolver properties that come from the database and “computed” properties like a fullName which is composed from user.firstName and user.lastName. Consider the following resolver:

type User = {
  firstName: string
  lastName: string
  fullName: string
}

const userResolver = resolve<User, Context>({
  properties: {
    fullName: async (_value, user, context) => {
      return `${user.firstName} ${user.lastName}`
    }
  }
})

Currently we don’t know if this property is completely computed or already exists in the database. Some of the repercussions in a Feathers app is that we can’t use the $select query syntax for resolvers because we don’t know what fields are in the database and which are dynamically resolved so a $select: [ 'fullName', 'firstName' ] would pass fullName as a field to select from to the database and causes an error. Additionally we don’t know that the fullName resolver requires a firstName and lastName to be present on the original data.

Suggestion

Create computed property resolver wrapper that indicates a computed property and optionally pass the names of the dependent fields (a fairly common pattern already in web development, e.g. in React hook effects). This could also address an additional concern brought up by @DaddyWarbucks that the value (the first argument) for a computed resolver will always be undefined. For the above example this would look like this:

import { resolve, computed } from '@feathersjs/schema'

type User = {
  firstName: string
  lastName: string
  fullName: string
}

const userResolver = resolve<User, Context>({
  properties: {
    fullName: computed<User, Context>(async (user, context) => {
      return `${user.firstName} ${user.lastName}`
    }, ['firstName', 'lastName'])
  }
})

It is a little more verbose but would allow tools using the resolver (like schemaHooks.resolveResult) to create a $select that is database friendly and also making sure that all dependent properties are selected.

Related to

• https://github.com/feathersjs/feathers/issues/2595
• https://github.com/feathersjs/feathers/issues/2604

[daffl]

Yeah I didn’t think computed was a great name either. My other thought was virtual. Looking at your snippets I’m actually wondering if this could address the other thing you were mentioning in executing dependent resolver properties as well 🤔

import _ from 'lodash'
import { resolve, computed } from '@feathersjs/schema'

type User = {
  firstName: string
  lastName: string
  fullName: string
  userName: string
}

const userResolver = resolve<User, Context>({
  properties: {
    userName: computed<User, Context>(async (user, context) => {
      return _.camelCase(user.fullName)
    }, ['fullName']),
    fullName: computed<User, Context>(async (user, context) => {
      return `${user.firstName} ${user.lastName}`
    }, ['firstName', 'lastName'])
  }
})

[daffl]

I’m going to close this since virtual property resolvers are now available. We can create a follow-up issue on how to handle dependencies.