This PR continues to bring more consistency to the API with default options for push and pull matching sync now (issue #22). Also, moving the optionsDB of the plugin into makeInstance() instead of only being applied by sync. This means that optionsDB is passed into all created databases even if those databases are local and don't require the remote options, or remote and don't require the local options. If there's a local option or a remote option that you want applied to only a single database, then don't put it in the optionsDB. If you had two remote databases and wanted to only modify the fetch method for one of those remote databases, then you wouldn't do it with optionsDB. For context:
Seems like this shouldn't be an issue since options for remote and local databases mostly don't overlap and will just be ignored if not applicable. The only option that does overlap is 'name' (https://pouchdb.com/api.html#create_database)
Also, a regression was introduced by moving the pouchOptions check before the api is created and returning early if no pouchOptions are found. It seemed mostly harmless, but had an unintended consequence. If there are no pouchOptions, then the api isn't created. Interestingly, there is a project that separates the api from the liveFind portion. In project Boatnet the api is placed in a service layer with no pouchOptions found, and then the service layer is called from other components where the pouchOptions have been specified and so liveFind works off of that.
The reason project Boatnet uses a service layer (wrapped in a vuex store which is then loaded as a module in the main vuex store) is so that some events (e.g. pouchdb-sync-update) can be captured and used to emit other custom events that determine Sync status. Then pouch component options are applied on other components. At least that's how I understand it from testing their code.
This PR continues to bring more consistency to the API with default options for push and pull matching sync now (issue #22). Also, moving the optionsDB of the plugin into makeInstance() instead of only being applied by sync. This means that optionsDB is passed into all created databases even if those databases are local and don't require the remote options, or remote and don't require the local options. If there's a local option or a remote option that you want applied to only a single database, then don't put it in the optionsDB. If you had two remote databases and wanted to only modify the fetch method for one of those remote databases, then you wouldn't do it with optionsDB. For context:
Seems like this shouldn't be an issue since options for remote and local databases mostly don't overlap and will just be ignored if not applicable. The only option that does overlap is 'name' (https://pouchdb.com/api.html#create_database)
Also, a regression was introduced by moving the pouchOptions check before the api is created and returning early if no pouchOptions are found. It seemed mostly harmless, but had an unintended consequence. If there are no pouchOptions, then the api isn't created. Interestingly, there is a project that separates the api from the liveFind portion. In project Boatnet the api is placed in a service layer with no pouchOptions found, and then the service layer is called from other components where the pouchOptions have been specified and so liveFind works off of that.
The reason project Boatnet uses a service layer (wrapped in a vuex store which is then loaded as a module in the main vuex store) is so that some events (e.g. pouchdb-sync-update) can be captured and used to emit other custom events that determine Sync status. Then pouch component options are applied on other components. At least that's how I understand it from testing their code.