Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion packages/platform-browser/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,8 @@
},
"devDependencies": {
"effect": "workspace:^",
"mock-xmlhttprequest": "^8.4.1"
"mock-xmlhttprequest": "^8.4.1",
"fake-indexeddb": "^6.2.5"
},
"dependencies": {
"multipasta": "^0.2.7"
Expand Down
111 changes: 111 additions & 0 deletions packages/platform-browser/src/IndexedDb.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,111 @@
/**
* @since 1.0.0
*/
import * as Config from "effect/Config";
import * as Effect from "effect/Effect";
import * as Layer from "effect/Layer";
import * as Schema from "effect/Schema";
import * as SchemaIssue from "effect/SchemaIssue";
import * as ServiceMap from "effect/ServiceMap";

/**
* @since 1.0.0
* @category type ids
*/
export const TypeId: unique symbol = Symbol.for(
"@effect/platform-browser/IndexedDb",
);

/**
* @since 1.0.0
* @category type ids
*/
export type TypeId = typeof TypeId;

/**
* @since 1.0.0
* @category models
*/
export interface IndexedDb {
readonly [TypeId]: TypeId;
readonly indexedDB: globalThis.IDBFactory;
readonly IDBKeyRange: typeof globalThis.IDBKeyRange;
}
Comment on lines +29 to +33
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on other Effect modules, it may make more sense to expose effectful service functions rather than the built-in interface. For example, as a rough sketch:

export interface IndexedDbFactory {
  readonly open: (name: string, version: number) => Effect.Effect<...>;
  readonly deleteDatabase: (name: string) => Effect.Effect<...>;
  readonly cmp: (first: IDBValidKey, second: IDBValidKey) => Effect.Effect<...>;
  readonly databases: Effect.Effect<...>;
}

export interface IndexedDbKeyRange {
  readonly only: (value: IDBValidKey) => Effect.Effect<...>;
  readonly lowerBound: (lower: IDBValidKey, open?: boolean) => Effect.Effect<...>;
  readonly upperBound: (upper: IDBValidKey, open?: boolean) => Effect.Effect<...>;
  readonly bound: (lower: IDBValidKey, upper: IDBValidKey, lowerOpen?: boolean, upperOpen?: boolean) => Effect.Effect<...>;
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep the service lean and then potentially expose another service that further extends it with effectful methods. Keeps it easily injectable for tests etc

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The effectful service could be added at a later date.


/**
* @since 1.0.0
* @category tag
*/
export const IndexedDb: ServiceMap.Service<IndexedDb, IndexedDb> =
ServiceMap.Service<IndexedDb, IndexedDb>(
"@effect/platform-browser/IndexedDb",
);

/**
* @since 1.0.0
* @category constructor
*/
export const make = (impl: Omit<IndexedDb, TypeId>): IndexedDb =>
IndexedDb.of({ ...impl, [TypeId]: TypeId });

/**
* Instance of IndexedDb from the `window` object.
*
* @since 1.0.0
* @category constructors
*/
export const layerWindow: Layer.Layer<IndexedDb, Config.ConfigError> =
Layer.effect(
IndexedDb,
Effect.suspend(() => {
if (window.indexedDB && window.IDBKeyRange) {
return Effect.succeed(
make({
indexedDB: window.indexedDB,
IDBKeyRange: window.IDBKeyRange,
}),
);
} else {
return Effect.fail(
new Config.ConfigError(
new Schema.SchemaError(
new SchemaIssue.MissingKey({
message: "window.indexedDB is not available",
}),
),
),
);
}
}),
);

/**
* Schema for `autoIncrement` key path (`number`).
*
* @since 1.0.0
* @category schemas
*/
export const AutoIncrement = Schema.Number.annotate({
identifier: "AutoIncrement",
title: "autoIncrement",
description: "Defines a valid autoIncrement key path for the IndexedDb table",
});
Comment on lines +88 to +92
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the standard (IndexedDB API 3.0), the autoIncrement key generator must be a positive integer not greater than 253. That check has been added here.

Suggested change
export const AutoIncrement = Schema.Number.annotate({
identifier: "AutoIncrement",
title: "autoIncrement",
description: "Defines a valid autoIncrement key path for the IndexedDb table",
});
export const AutoIncrement = Schema.Number
.check(Schema.isInt(), Schema.isBetween({ minimum: 1, maximum: 2 ** 53 }))
.annotate({
identifier: "AutoIncrement",
title: "autoIncrement",
description: "Defines a valid autoIncrement key path for the IndexedDb table",
});

Copy link
Collaborator

@tim-smart tim-smart Feb 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Schema.Int.check(Schema.isBetween({ minimum: 1, maximum: 2 ** 53 }))


/** @internal */
const IDBFlatKey = Schema.Union([
Schema.String,
Schema.Number,
Schema.Date,
Schema.declare(
(input): input is BufferSource =>
input instanceof ArrayBuffer || ArrayBuffer.isView(input),
),
]);

/**
* Schema for `IDBValidKey` (`number | string | Date | BufferSource | IDBValidKey[]`).
*
* @since 1.0.0
* @category schemas
*/
export const IDBValidKey = Schema.Union([IDBFlatKey, Schema.Array(IDBFlatKey)]);
Comment on lines +94 to +111
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • This can be simplified by using Schema.suspend to define the recursive schema.
  • According to the standard (IndexedDB API 3.0), only a subset of the types provided are valid keys. Notably these types differ:
    • number (excluding NaN)
    • Date (excluding any invalid Date)
  • Effect 4.0 does not currently have an equivalent for Schema.NonNaN, a Schema.isNonNaN filter could be added to further simplify this check.
  • Schema.mutable is used because the built-in DOM declaration defines IDBValidKey with a mutable type IDBValidKey[]. Alternatively, a type may be defined with readonly IDBValidKey[] (Readonly<IDBValidKey> errors)
Suggested change
/** @internal */
const IDBFlatKey = Schema.Union([
Schema.String,
Schema.Number,
Schema.Date,
Schema.declare(
(input): input is BufferSource =>
input instanceof ArrayBuffer || ArrayBuffer.isView(input),
),
]);
/**
* Schema for `IDBValidKey` (`number | string | Date | BufferSource | IDBValidKey[]`).
*
* @since 1.0.0
* @category schemas
*/
export const IDBValidKey = Schema.Union([IDBFlatKey, Schema.Array(IDBFlatKey)]);
/**
* @since 1.0.0
* @category schemas
*/
export const IDBValidKey: Schema.Schema<IDBValidKey> = Schema.Union([
Schema.String,
Schema.Number.check(Schema.makeFilter((input) => !Number.isNaN(input))),
Schema.DateValid,
Schema.declare((input): input is BufferSource =>
input instanceof ArrayBuffer ||
ArrayBuffer.isView(input) && input.buffer instanceof ArrayBuffer
),
Schema.mutable(Schema.Array(Schema.suspend(() => IDBValidKey))),
]);

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use Schema.Finite for finite numbers. I think it excludes nan too

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would avoid using suspend here and keep it as it was.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tim-smart

You can use Schema.Finite for finite numbers. I think it excludes nan too

Schema.Finite would be too restrictive since it excludes Infinity and -Infinity, which are valid keys according to the standard.

I would avoid using suspend here and keep it as it was.

No suspend is fine as it's functionally equivalent.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK if infinite is permitted then the nan check is fine.

suspend works, but you end up with a better schema ast without it.

Loading