`stores` defined as object

[wtgtybhertgeghgtwtg]

Instead of defining stores as

const stores = {
  storeOne: [
    ['someCollection', 'someKey'],
    ['someOtherCollection', 'someOtherKey'],
  ],
  storeTwo: [
    ['someThirdCollection', 'someThirdKey'],
  ],
};

why not something like

const stores = {
  storeOne: {
    someCollection: 'someKey',
    someOtherCollection: 'someOtherKey',
  },
  storeTwo: {
    someThirdCollection: 'someThirdKey',
  },
}

[piglovesyou]

Hi, @wtgtybhertgeghgtwtg . store.createIndex() accepts the third argument as "optionalObjectParameters". How can you design a cleaner API for that?

I guess that's why ;)

[wtgtybhertgeghgtwtg]

const stores = {
  storeOne: {
    // objectIndexName will be 'someCollection', objectKeyPath will be 'someKey'
    someCollection: 'someKey',
    // objectIndexName will be 'someOtherCollection', objectKeyPath will be 'someOtherKey', optionalObjectParamaters will be 'optionalParameters'
    someOtherCollection: {
      objectKeyPath: 'someOtherKey',
      optionalObjectParameters: 'optionalParameters',
  },
}

[piglovesyou]

Thank you for the concrete example. That'd be the answer as a matter of fact. And I understand it'd be more kind to people who doesn't know the native IDBObjectStore.createIndex() interface.

The reason I prefer the current API is that I want SyncedDB to be "raw" as much as possible. The option (['someCollection', 'someKey']) goes to store.createIndex.apply(store, option) and I feel it's simple, fast and enough flexible.

I admit the object argument is not understandable at first. Here why don't we just modify API.md, instead of starting if (typeof storeOpts[indexName] === 'string')?

[wtgtybhertgeghgtwtg]

As you will.

[paldepind]

Yes. What @piglovesyou wrote is excactly the reason why I originally went with the current design.

I also considered teh same as your proposal @wtgtybhertgeghgtwtg. But while it looks simpler at first it introduces an edge case and one will have to design a workaround as you did. In my opinion this ends up making the API less simple compared to the current where the third argument is handled seamlessly.