xbyorange / mercury Goto Github PK

It is desirable to provide a property that allows to identify unequivocally different instances of Mercury origins or selectors.

This issue is related with the XbyOrange/react-mercury#22

It is desirable that all mercury-based origins implement a "config" method that should allow to configure multiple instances at a time, as it is done using the "config" method of mercury-api package.
Having this method defined as "native" of mercury, it will not be necessary to define it in every new mercury origin.

Status badges in README file are not being properly displayed.

It is desirable to add more details about current resource status when a changeor changeAny event is emitted.
A new data property could be added to the emitted object in the case of changeAny event. This property should contain current values of loading, error and value.

For change events, that currently are emitting only the method name, this should be replaced by an object containing method and data properties, but this change implies a breaking change in the event interface, and this fact has to be taked into account before making the change ¿Does it really improve the interface enough to assume the risk of a breaking change?

The "docs/sources/api.md" document does not mention the "config" method, which will be probably the most used.

It is desirable to complete the documentation adding this method.

When a cleanAny event is emitted, a _root property is available in the event data that allows to identify the source being cleaned. This property is not available for cleanAny event of Selectors, it only works for Origins.

The problem seems to be related to the _readAllSourcesAndDispatchmethod of Selector class, which is using the this._cache.clean method to clean the cache instead of the this._clean one.

Describe the bug
Unable to retrieve the callback function passed as catch

To Reproduce
Given the selector

export const selector = new Selector(
  {
    source: origin,
    query: query => query,
    catch: () => false // this callback
  },
  data => data
);

and in the test file

  describe("catch", () => {
    it("should return false if error", () => {
      const catchCallback = selector.test.catch;

      expect(catchCallback()).toBe(false);
    });
  });

Expected behavior
catchCallback is the function provided and test passed

Describe the bug
When we have multiple sources on parallels the selector test function not return defined query.

To Reproduce

const selector = new Selector(
 [{
    source: origin1,
    query: filter => filter
  },
  origin2,
  ...
  ],
  (result1, result2) => {...}
);

Expected behavior
On your selector test:

...
const fn = selector.test.queries[0]; // should return query function to test
fn("foo")
...

Migrate library from private library and publish it to NPM public registry, under the @XbyOrange scope.

The customQueries property described in the docs does not exist. It is described here: https://github.com/XbyOrange/mercury/blob/master/docs/selector/testing.md, but, when trying to use it, it is not defined. It is desirable to implement a getter in the Origin base class in order to expose the private property _customQueries.

In some scenarios could be desirable to modify configuration only for certain invocations to the "read" method. (For example, when passing an "idempotency-key" as an http header using "mercury-api")

This options could be passed as a parameter to the "read" method, and should override instance options only for that execution. For other methods, such as "create" or "update", options could be passed as second argument.

Currently there is no property in "queried" instances that could allow to identify unequivocally to which root instance it belongs.
To develop Mercury addons and other advanced elements it could be desirable to recognize the root element of a queried element, so a _rootId property , or even a _root property (which could contain a complete reference to the root object) can be very useful.

Currently the Origin base class stores directly the received defaultValue argument as its _defaultValue private property, which is returned afterwards as value property of read methods until the real value is retrieved asynchronously.

As described in the issues XbyOrange/mercury-memory#3 and XbyOrange/mercury-browser-storage#3, it is needed to implement some specific behaviors for default values depending of the specific origin implementation. To do this, it is desirable that the Origin class could accept a defaultValue defined as a callback function which will receive the query argument. So specific origins implementations could implement their own behaviors for default values using this callback.

Here, an example of how could the callback be used when implementing a new Origin:

import { Origin } from "@xbyorange/mercury";

export class FooOrigin extends Origin {
  constructor(id, defaultValue) {
    const getDefaultValue = query => {
      return query ? defaultValue[query] : defaultValue;
    };
    super(id, getDefaultValue);
  }
}

Currently you can know if a resource is loading or not, and you can know his value using the loading and value properties, but, in some scenarios, it is neccesary to know if it has been loaded for the first time.

For example, if a source could return a value of undefined and you have to act in consequence, it is not possible to determine if the resource has not still been loaded (will have a value of undefined too) , or if it has finish loading and his value is really undefined:

First state:

{
  "value":undefined,
  "loading": false,
  "error":null
}

Someone dispatchs the read method, then:

{
  "value":undefined,
  "loading": true,
  "error":null
}

When it finish loading, and returns undefined:

{
  "value":undefined,
  "loading": false,
  "error":null
}

As seen in the examples, in this scenario the states 1 and 3 are exactly the same, and thay can't be distinguished.

It is desirable to add a new loaded property which could contain a count of times that resource has been loaded. Then, previous described examples will become:

{
  "value":undefined,
  "loading": false,
  "error":null,
  "loaded": 0
}

Someone dispatchs the read method, then:

{
  "value":undefined,
  "loading": true,
  "error":null,
  "loaded": 0
}

When it finish loading, and returns undefined:

{
  "value":undefined,
  "loading": false,
  "error":null,
  "loaded": 1
}

This counter should be increased only when caches are cleaned and the resource is really loaded.

Actually it's possible to define a selector which can return another source, but just one. It'd be interesting to return multiple sources in an array. This new feature would allow the management of complex scenarios like concurrent accesses with dynamic queries.