-
Notifications
You must be signed in to change notification settings - Fork 89
(DOCSP-15613): Node.js collections type #1044
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 6 commits
37c5a5b
ed0a475
9c52218
546f6f9
aec1cfc
9df9602
037dd7e
b1f88fe
f65f804
233d37a
7edfda7
a1a1b12
ad18ac7
6d16272
21a5e34
8775ba5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,3 +14,124 @@ Collections - Node.js SDK | |
|
||
Overview | ||
-------- | ||
|
||
{+service-short+} has several types to represent groups of objects, | ||
which we call **collections**. A collection is an object that contains | ||
zero or more instances of one :ref:`{+service-short+} type | ||
<node-object-types>`. {+service-short+} collections are **homogenous**: | ||
all objects in a collection are of the same type. | ||
|
||
You can filter and sort any collection using {+client-database+}'s | ||
:ref:`query engine <node-client-query-engine>`. Collections are | ||
:ref:`live <node-live-objects>`, so they always reflect the current state | ||
of the :term:`{+realm+} instance` on the current thread. You can also | ||
listen for changes in the collection by subscribing to :ref:`collection | ||
notifications <node-register-a-collection-change-listener>`. | ||
|
||
.. _node-realm-results: | ||
|
||
Results | ||
------- | ||
A :js-sdk:`Results <Realm.Results.html>` collection represents the | ||
lazily-evaluated results of a query operation. Results are immutable: | ||
you cannot add or remove elements to or from the results collection. | ||
Results have an associated query that determines their contents. | ||
|
||
.. seealso:: | ||
|
||
:ref:`Reads <node-realm-database-reads>` | ||
|
||
.. _node-realm-list: | ||
|
||
Lists | ||
----- | ||
A :js-sdk:`List <Realm.List.html>` represents a :ref:`to-many | ||
relationship <node-to-many-relationship>` between two {+service-short+} | ||
types. Lists are mutable: within a write transaction, you can add and | ||
remove elements to and from a list. Lists are not associated with a | ||
query and are declared as a property of an :ref:`object model | ||
<node-object-schemas>`. | ||
|
||
.. seealso:: | ||
|
||
:ref:`To-Many Relationships <node-to-many-relationship>` | ||
|
||
.. _node-lazy-evaluated-results: | ||
|
||
Results are Lazily Evaluated | ||
---------------------------- | ||
{+client-database+} only runs a query when you actually request the | ||
results of that query. This lazy evaluation enables you to write | ||
elegant, highly performant code for handling large data sets and complex | ||
mohammadhunan-dev marked this conversation as resolved.
Show resolved
Hide resolved
|
||
queries. | ||
|
||
.. _node-live-collections: | ||
|
||
Collections are Live | ||
-------------------- | ||
Like :ref:`live objects <node-live-objects>`, {+service-short+} collections | ||
are usually **live**: | ||
|
||
- Live results collections always reflect the current results of the associated query. | ||
- Live lists always reflect the current state of the relationship on the {+realm+} instance. | ||
|
||
A collection is **not** live when: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is weirdly formatted on staging. I think you're missing an empty line after this line and it's all running together as a single paragraph. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see that now, fixed 👍 |
||
- the collection is enumerated using a :mdn:`for..in <Web/JavaScript/Reference/Statements/for...in>` or :mdn:`for..of <Web/JavaScript/Reference/Statements/for...of>` statement. ``for...in`` and ``for...of`` enumerate over the objects which matched the query when the enumeration is begun even if some of them are deleted or modified to be excluded by the filter during the enumeration. | ||
mohammadhunan-dev marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- the collection is a frozen :js-sdk:`Results.snapshot() <Realm.Collection.html#snapshot>` | ||
|
||
Combined with :ref:`collection notifications | ||
<node-change-notifications>`, live collections enable clean, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: "clean" code seems a bit like jargon. If you mean something specific by this, such as "easy to maintain" or "good separation of responsibilities" - perhaps we could use that specific phrase instead? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair point, removed the word clean here - it's a bit redundant to "reactive" |
||
reactive code. For example, suppose your view displays the | ||
results of a query. You can keep a reference to the results | ||
collection in your view class, then read the results | ||
collection as needed without having to refresh it or | ||
validate that it is up-to-date. | ||
|
||
.. important:: Indexes may change | ||
|
||
Since results update themselves automatically, do not | ||
store the positional index of an object in the collection | ||
or the count of objects in a collection. The stored index | ||
or count value could be outdated by the time you use | ||
it. | ||
|
||
.. _node-working-with-collections: | ||
|
||
Working With Collections | ||
------------------------ | ||
|
||
.. _node-limiting-query-results: | ||
|
||
Limiting Query Results | ||
~~~~~~~~~~~~~~~~~~~~~~ | ||
As a result of lazy evaluation, you do not need any special | ||
mechanism to limit query results with {+client-database+}. For example, if | ||
your query matches thousands of objects, but you only want | ||
to load the first ten, simply access only the first ten | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: "simply access only" reads a bit weird. Maybe drop the "simply" or put in something like: "you can specifically access the first ten..." or "limit the results to the first ten..." There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair point, removed "simply" 👍 |
||
elements of the results collection. | ||
|
||
.. _node-realm-result-pagination: | ||
|
||
Pagination | ||
~~~~~~~~~~ | ||
Thanks to lazy evaluation, the common task of pagination | ||
becomes quite simple. For example, suppose you have a | ||
results collection associated with a query that matches | ||
thousands of objects in your {+realm+}. You display one hundred | ||
objects per page. To advance to any page, simply access the | ||
elements of the results collection starting at the index | ||
that corresponds to the target page. | ||
|
||
Summary | ||
------- | ||
- A {+service-short+} **collection** is a homogenous container of zero | ||
or more instances of one | ||
:ref:`{+service-short+} type <node-object-types>`. | ||
- There are two main kinds of collection: **lists** and **results**. | ||
Lists define the :ref:`to-many relationships <node-to-many-relationship>` | ||
of your {+service-short+} types, while results represent the | ||
lazily-loaded output of a :ref:`read operation <node-realm-database-reads>`. | ||
- Lazy evaluation of results collections means there is no need to | ||
design a special query to get limited or paginated results. Perform | ||
the query and read from the results collection as needed. | ||
- Data in {+service-short+} is *live*, which means that an object always reflects its most recent saved state. |
Uh oh!
There was an error while loading. Please reload this page.