Changelog
12.0.0-alpha.1 (2023-03-22)
This is a pre-release of the next major version of our SDK. Please read more and discuss in the dedicated discussion: https://github.com/realm/realm-js/discussions/5416 See the release notes of previous pre-releases below for a complete picture of the changes introduced since v11.
require
from Node.js would throw because it would accidentally import the ESM bundle. (#5607, since v12.0.0-alpha.0)Changelog
12.0.0-alpha.0 (2023-03-21)
This is the first pre-release of the next major version of our SDK. Please read more and discuss in the dedicated discussion: https://github.com/realm/realm-js/discussions/5416
Although this is a complete rewrite of our SDK, we've strived to keep breakages to a minimum and expect our users to upgrade from v11 without any significant changes to their code-base.
module.export = Realm
style), which would allow CommonJS runtimes like Node.js to import us using a simple assignment:const Realm = require("realm"); // this commonjs style - won’t work anymore
From now on, users need to consume us using a named import, like this:
const { Realm } = require("realm"); // commonjs style
import { Realm } from "realm"; // esm style
import * as realm from "realm"; // esm namespaced style for more explicit usage like realm.List and realm.Object
import Realm from "realm"; // esm style - consuming our "default" export
Results
, List
and Set
used to inherit directly from Collection
but now inherits from an abstract OrderedCollection
, which extends Collection
.PropertySchema
and PropertySchemaShorthand
types.)// Example object schema
const TaskSchema = {
name: "Task",
properties: {
description: /* property schema (shorthand or object form) */,
},
};
// Explicitness
"[]" // Bad (previously parsed as implicit "mixed")
"mixed[]" // Good
{ type: "list" } // Bad
{ type: "list", objectType: "mixed" } // Good
// Mixing shorthand and object form
{ type: "int[]" } // Bad
"int[]" // Good
{ type: "list", objectType: "int" } // Good
{ type: "int?" } // Bad
"int?" // Good
{ type: "int", optional: true } // Good
// Specifying object types
{ type: "SomeType" } // Bad
"SomeType" // Good
{ type: "object", objectType: "SomeType" } // Good
{ type: "object[]", objectType: "SomeType" } // Bad
"SomeType[]" // Good
{ type: "list", objectType: "SomeType" } // Good
{ type: "linkingObjects", objectType: "SomeType", property: "someProperty" } // Good
instanceof SomeClass
checks, however, code which is directly using prototype or constructor comparisons will fail:Object.getPrototypeOf(object) == CustomObject.prototype // No longer works
object.constructor == CustomObject // No longer works
Symbol
type). In the new SDK, using a Symbol as a key in a dictionary will throw.{...obj}
and introduced Realm.Object#keys()
, Realm.Object#entries()
and Realm.Object#toJSON()
methods were introduced as a workaround. The new SDK wraps its accessor objects in a Proxy trapping the ownKeys operation which enables calls to the standard Object.keys(obj)
and the spread operator {...obj}
to work correctly, with minimal performance impact on normal accesses. Therefore, we are deprecating the APIs with the @deprecation annotation and a console.warn
when calling RealmObject#keys() and RealmObject#entries(). RealmObject#toJSON still serves the purpose of producing a circularly referencing object graph. We would love the community's feedback on this![...realm.subscriptions]
). (The property length
is available.) Again, something we would love feedback on.ObjectPropsType
, UserMap
, UserType
, BaseFunctionsFactory
, AuthProviders
, PropertyType
, HTTP
, *Details
interfaces of the EmailPasswordAuthClient
and AuthError
types, since they weren't used internally and not expected to be used by users. Moreover, most of these are very simple to type out for any user relying on it. Similarly, the DictionaryBase
type was introduced to help work around an issue (declaring string index accessors on a class with methods) in our declarations. We consider it an internal detail that got introduced as part of our public API by accident; thus, we ask users to use the Dictionary
type directly. We also decided to rename the Session
class to SyncSession
since it’s now exported directly on the package namespace. Session
will still be available (but deprecated) as Realm.Sync.Session
. We’re no longer using the *Payload
types (they were only used by Realm Web) and we don’t expect end-users to be relying directly on these, hence they will be deleted."list"
instead of "array"
.Object.keys(obj)
and the spread operator {...obj}
on RealmObject
s. We still recommend explicitly only accessing the fields you need rather than using spreads. Spreads eagerly access all fields in the object, which can have significant performance costs if some fields are not actually needed. (#1299, #2640, #2844)SyncConfiguration.cancelWaitsOnNonFatalError
, which defaults to false. When set to true, all async operations (such as opening the Realm using Realm.open()
) will fail when a non-fatal error, such as a timeout, occurs.Object.linkingObjects
method that takes type of the linking object as an input instead of its string name (#5326)
Example usage:let linkedObjects = john.linkingObjects(Person, "friends");
Dictionary.set
method that takes two arguments, a key
and a value
. (#4286)
Example usage:realm.write(() => {
item.dictionary.set("key", "value");
});
list.remove(index)
: removes the element of the list at the specified index.list.move(from, to)
: moves one element of the list from one index to another.list.swap(index1, index2)
: swaps the positions of the elements of the list at two indexes.master
branch to main
.