Skip to content
Snippets Groups Projects
Store-doc.rst 4.64 KiB
Newer Older
.. _store-documentation:

Store documentation
====================

The store is responsible for the communication between the framework and the servers. You may need to use some of its functions.
To use the store in your application, make sure to import it from the root of sib-core:

.. code:: js

  import { store } from 'https://unpkg.com/@startinblox/core';


API Reference
-------------


``getData`` (``async``)
^^^^^^^^^^^^^^^^^^^^^^^

Fetch and cache the data for a resource

**parameters**
* ``id: string``: uri of the resource
* ``context: object`` (optional):  used to expand the ``id`` and to access the resource predicates from a compact form

**returns**
* ``resource: Proxy``

Synchronously returns a resource from the cache.

**parameters**
* ``id: string``: uri of the resource

**returns**
* ``resource: Proxy``: or ``null`` if the resource is not in cache
``post`` (``async``)
^^^^^^^^^^^^^^^^^^^^^^

Send a POST request to create a resource in a container. When the request succeed, the resource is cleared from the cache, and the components showing it are notified.

**parameters**
* ``resource: object``: values of the resource to create
* ``id: string``: uri of the container

**returns**
* ``resourceId: string``: id of the created resource
``put`` (``async``)
^^^^^^^^^^^^^^^^^^^^^

Send a PUT request to edit a resource. When the request succeed, the resource is cleared from the cache, and the components showing it are notified.

**parameters**
* ``resource: object``: new values of the resource to edit
* ``id: string``: uri of the resource

**returns**
* ``resourceId: string``: id of the edited resource
``patch`` (``async``)
^^^^^^^^^^^^^^^^^^^^^^^

Send a PATCH request to edit a resource. When the request succeed, the resource is cleared from the cache, and the components showing it are notified.

**parameters**
* ``resource: object``: new values of the resource to edit
* ``id: string``: uri of the resource

**returns**
* ``resourceId: string``: id of the edited resource
``delete`` (``async``)
^^^^^^^^^^^^^^^^^^^^^^^^

Send a DELETE request to delete a resource. When the request succeed, the resource is cleared from the cache, and the components showing it are notified.

**parameters**
* ``id: string``: uri of the resource to delete
* ``context: object`` (optional): used to expand the id if needed

**returns**
* ``resourceId: string``: id of the deleted resource
``subscribeTo``
^^^^^^^^^^^^^^^^

Make a resource listen another one. When a change is detected on a resource, all the resources which are listening are removed from the cache, and the component showing them are notified to re-render their content.

**parameters**
* ``resourceToUpdate``: resource which needs to be updated when another one change
* ``resourceToListen``: resource on which listen for changes
``clearCache``
^^^^^^^^^^^^^^^

Manually remove a resource from the cache

**parameters**
* ``id``: uri of the resource to remove from the cache
.. _selectLanguage:
``selectLanguage``
^^^^^^^^^^^^^^^^^^

Select the language to use to fetch data. If the data is not available, English is served by default.

**parameters**

* ``language``: code of the language. ie: ``fr``



Store reactivity
----------------

The store is reactive. It means that any change you make on a resource in your app will be reflected in the interface automatically.
However, there are some limitations:
Matthieu Fesselier's avatar
Matthieu Fesselier committed

* If you make some changes on a resource which is in a virtual container, other virtual containers including this resource may not be updated. (ie: POST on ``circles/1/members`` does not update ``users/admin/circles/``)
* If a resource having a multi nested field is displayed in a component, it may not be updated. (ie: in a ``sib-display``, I display ``nestedResource.user.name`` from ``resource``, changing ``user`` will not update the display)
In response to these two cases, the store method ``subscribeVirtualContainerTo(arg1, arg2)`` allows changes in one resource to be passed on to another reactively:
  - ``arg1`` is the resource to be updated according to ``arg2``,
  - ``arg2`` is the starting resource, the model to copy.

The following example illustrates the reactivity of a component displaying job offers.
A container is providing a list of job offers (``http://localhost/job-offers/active/``), another endpoint is used to create new job offers (``http://localhost/job-offers/``). Each time a job offer is created (added to ``http://localhost/job-offers/``), the displayed list of job offers (``http://localhost/job-offers/active/``) requires an update:
  core.store.subscribeVirtualContainerTo(http://localhost/job-offers/active/, http://localhost/job-offers/);