npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

pocketbase-ts

v1.2.5

Published

Pocketbase SDK wrapper with more readable option syntax and better typings

Downloads

304

Readme

PocketBase Typed SDK

A small wrapper around the official PocketBase JavaScript SDK that allows you to write options in a more human-readable way, and also types the response for you.

This is how you would normally write options for the PocketBase SDK:

const postsWithAuthorAndComments = await pb.collection('posts').getFullList({
	expand: 'author,comments_via_post'
	fields: 'id,title,expand.author.id,expand.author.name,expand.comments_via_post.id,expand.comments_via_post.message',
})

Writing options manually like this is very error-prone, and makes the code very hard to read and maintain.

This wrapper allows you to write it like this instead:

const postsWithAuthorAndComments = await pb.collection('posts').getFullList({
	fields: ['id', 'title'],
	expand: [
		{ key: 'author', fields: ['id', 'name'] },
		{
			key: 'comments_via_post',
			fields: ['id', 'message'],
		},
	],
})

It comes with autocomplete for key, fields, expand, filter, and sort options, and also properly types the response as:

Pick<Post, 'id' | 'title'> & {
	expand: {
		author: Pick<User, 'id' | 'name'>
		comments_via_post?: Pick<Comment, 'id' | 'message'>[]
	}
}

You can try it out in TS Playground

Installation

npm install pocketbase-ts
pnpm add pocketbase-ts

Usage

Defining schema

[!TIP] I recommend using this hook to generate the schema during development.
It will watch for any changes made to the collections and update the schema file accordingly, keeping everything in sync.

Below is an example of how you would define the schema for this in the PocketBase docs.

interface PocketBaseCollection {
	id: string
	created: string
	updated: string
}

interface User extends PocketBaseCollection {
	name: string
}

interface Post extends PocketBaseCollection {
	// relation fields are defined as strings because they are IDs of the related items
	author: string
	title: string
	tags: Array<string>
}

interface Tag extends PocketBaseCollection {
	name: string
}

interface Comment extends PocketBaseCollection {
	post: string
	user: string
	message: string
}

// you need to use "type" instead of "interface" here
type Schema = {
	// collection name as key
	users: { type: User }
	posts: {
		type: Post
		relations: {
			// field name as key
			author: User
			// add "?" modifier to annotate optional relation fields
			tags?: Array<Tag>
		}
	}
	tags: { type: Tag }
	comments: {
		type: Comment
		relations: {
			post: Post
			user: User
		}
	}
}

[!NOTE] Back-relations will automatically be inferred from the schema, so in most cases, you don't need to define them yourself.
However, in some cases, you may need to define them explicitly. See Caveats for more information.

Instantiating the SDK

import { PocketBaseTS } from 'pocketbase-ts'

const pb = new PocketBaseTS<Schema>('http://127.0.0.1:8090')

Building query

Use it just like you would with the official SDK, but with a more readable option syntax:

const result = await pb.collection('posts').getOne({
	// you can specify fields to be returned in the response
	fields: ['id', 'title', 'tags'],
	expand: [
		{
			// returns all fields if not specified
			key: 'author',
		},
		{
			key: 'comments_via_post',
			// you can use `:excerpt` modifier on string fields
			fields: ['message:excerpt(20)'],
			// nesting `expand` is supported
			expand: [{ key: 'user', fields: ['name'] }],
		},
	],
})

The result is automatically typed as:

Pick<Post, "tags" | "id" | "title"> & {
	expand: {
		author: User
		comments_via_post?: (Pick<Comment, "message"> & {
			expand: {
				user: Pick<User, "name">
			}
		})[]
	}
}

Helper for filter & sort

While you can still write filter and sort as string, you can also use the provided $ tagged template literal helper to get intellisense for the field names.

const result = await pb.collection('posts').getFullList({
	filter: ({ $ }) => $`${'author.role'} = "admin" && ${'comments_via_post.message'} ?~ 'hello'`,
	sort: ({ $ }) => $`${'created'},${'author.name'}`,
	expand: [{ key: 'comments_via_post' }],
})

This function is merely there to provide you with intellisense and help mitigate typos. It does not do any type narrowing or validation.
(i.e. the example above will still have ? modifier on expand in the response type.)

Maximum expand depth

While PocketBase supports expanding relations up to 6 levels deep, the number of fields increases exponentially with each level.
The performance hit was very noticeable when I tried to set it to 6 even with the simple schema in the example above.

As such, I've set the maximum depth to 2 by default.

However, should you wish to expand further, you can adjust the maximum depth by passing it as the second type argument when instantiating the SDK.

const pb = new PocketBaseTS<Schema, 6>('')

Type for Schema:

interface SchemaDeclaration {
	[collectionName: string]: {
		type: Record<PropertyKey, any> // collection type
		relations?: {
			[fieldName: string]: Record<PropertyKey, any> // relation type
		}
	}
}

Handling of expand

Let's say you want to fetch a post with its comments using expand.
When the post doesn't have any comments, the SDK (or PocketBase itself rather) returns something like this:

{
	id: "1",
	title: "Lorem ipsum",
	tags: ["lorem", "ipsum"],
	created: "2024-01-01T00:00:00.000Z",
	updated: "2024-01-01T00:00:00.000Z"
}

The response will not have

{
	expand: {
		comments_via_post: []
	}
}
// or not even { expand: undefined } for that matter

So you will get a runtime error if you try to access post.expand.comments_via_post on a post with no comments.

To handle cases like this, the wrapper will add the ? modifier to expand itself if all the specified expands are for optional relation fields.

Post & {
	expand?: {
		comments_via_post: Comment[]
	}
}
// or with multiple optional relations
Post & {
	expand?: {
		tags?: Tag[]
		comments_via_post?: Comment[]
	}
}

If you expand it along with fields that are not optional like author, expand will be present regardless of whether the post has comments or not.

So the response will be typed as:

Post & {
	expand: {
		author: User
		comments_via_post?: Comment[]
	}
}

Caveats:

Back-relations

By default, all back-relations are treated as nullable (e.g. Post may not have any Comment), and to-many (e.g. comments_via_post will be of type Comment[]).
The former can be dealt with by simply adding the non-null assertion operator !, but the latter is a different story.

If you have a UNIQUE index constraint on the relation field, the item in expand will be of type T instead of T[].

In such case, you can override the default behaviour by explicitly defining back-relations yourself in the schema.

type Schema = {
	...
	users: {
		type: User
		relations: {
			...
-			userDetail_via_user?: UserDetail[] // default (implicit/inferred)
+			userDetail_via_user: UserDetail // made non-nullable by removing the `?`
		}
	}
	...
}

Dealing with tables with exactly the same properties

In the example above, User and Tag have the exact same shape, and there is no way for TypeScript to differentiate between the two.
To make it clear to TypeScript that they are different, you can use the UniqueCollection utility type provided by this package.

import type { UniqueCollection } from 'pocketbase-ts'

// pass in the collection name as the second type argument to ensure uniqueness
type User = UniqueCollection<{ name: string } & PocketBaseCollection, 'users'>

Without this, TypeScript will confuse back-relations pointing to User and Tag and suggest that users can be expanded with posts_via_tags, etc.