The head note of 0.25 is now in [updates_old.md](https://github.com/vrtmrz/obsidian-livesync/blob/main/updates_old.md). Because 0.25 got a lot of updates, thankfully, compatibility is kept and we do not need breaking changes! In other words, when get enough stabled. The next version will be v1.0.0. Even though it my hope.
We are finally ready for release. I think I will go ahead and release it after using it for a few days.
### Fixed
- Hidden file synchronisation now works!
- Now Hidden file synchronisation respects `.ignore` files.
- Replicator initialisation during rebuilding now works correctly.
### Refactored
- Some methods naming have been changed for better clarity, i.e., `_isTargetFileByLocalDB` is now `_isTargetAcceptedByLocalDB`.
### Follow-up tasks memo (After 0.25.44)
Going forward, functionality that does not span multiple events is expected to be implemented as middleware-style functions rather than modules based on classes.
Consequently, the existing modules will likely be gradually dismantled.
For reference, `ModuleReplicator.ts` has extracted several functionalities as functions.
However, this does not negate object-oriented design. Where lifecycles and state are present, and the Liskov Substitution Principle can be upheld, we design using classes. After all, a visible state is preferable to a hidden state. In other words, the handler still accepts both functions and member methods, so formally there is no change.
As undertaking this for everything would be a bit longer task, I intend to release it at this stage.
Note: I left using `setHandler`s that as a mark of `need to be refactored`. Basically, they should be implemented in the service itself. That is because it is just a mis-designed, separated implementation.
Last time, since I found a bug, I ended up doing a few other things as well, but next time I intend to release it with just the bug fix. It is quite substantial, after all.
Customisation Sync has mostly been verified. Hidden file synchronisation has not been done yet.
- Fixed an issue where the StorageEventManager was not correctly loading the settings.
- Replication statistics are now correctly reset after switching replicators.
### Refactored
- Now, many reactive values which keep the state or statistics of the plugin are moved to the services which have the responsibility for these states.
-`serviceFeatures` are now able to be added to the services; this is not a class module, but a function which accepts dependencies and returns an addHandler-able function. This is for better separation of concerns, better maintainability, and testability.
-`control` service; is a meta-service which is responsible for orchestrating services has been added.
- Don't you think stopping replication or something occurs during `settingService.realiseSetting` is quite weird? It may be done by the control service, which can orchestrate the setting service and the replicator service.
-
- Some functions on services have been moved. e.g., `getSystemVaultName` is now on the API service.
- Setting Service is now responsible for the setting, no longer using dynamic binding for the modules.
- Now `StorageEventManagerBase` is separated from `StorageEventManagerObsidian` following their concerns.
- No longer using `ObsidianFileAccess` indirectly during checking duplicated-file events.
- Last event memorisation is now moved into the StorageAccessManager, just like the file processing interlocking.
- These methods, i.e., `ObsidianFileAccess.touch`. `StorageEventManager.recentlyTouched`, and `StorageEventManager.touch` are still available, but simply call the StorageAccessManager's methods.
- Now `FileAccessBase` is separated from `FileAccessObsidian` following their concerns.
- Not so long from now, ServiceFileAccessObsidian might be abstracted to a more general FileAccessService, and make more testable and maintainable.
- These properties are initialised in `initialiseServiceModules` on `ObsidianLiveSyncPlugin`.
- They are `ServiceModule`s.
- Which means they do not use dynamic binding themselves, but they use bound services.
- ServiceModules are in src/lib/src/serviceModules for common implementations, and src/serviceModules for Obsidian-specific implementations.
- Hence, now all ambiguous properties of `ObsidianLiveSyncPlugin` are initialised explicitly. We can proceed to testing.
- Well, I will release v0.25.44 after testing this.
- Conflict service is now responsible for `resolveAllConflictedFilesByNewerOnes` function, which has been in the rebuilder.
- New functions `updateSettings`, and `applyPartial` have been added to the setting service. We should use these functions instead of directly writing the settings on `ObsidianLiveSyncPlugin.setting`.
- Some interfaces for services have been moved to src/lib/src/interfaces.
-`RemoteService.tryResetDatabase` and `tryCreateDatabase` are now moved to the replicator service.
- You know that these functions are surely performed by the replicator.
- Probably, most of the functions in `RemoteService` should be moved to the replicator service, but for now, these two functions are moved as they are the most related ones, to rewrite the rebuilder service.
- Common functions are gradually moved to the common library.
- Now, binding functions on modules have been delayed until the services and service modules are initialised, to avoid fragile behaviour.
I have been working on it little by little in my spare time. Sorry for the delayed response for issues! ! However, thanks for your patience, we seems the `revert to 0.25.43` is not necessary, and I will keep going with this version.
### Refactored
- No longer `DatabaseService` is an injectable service. It is now actually a service which has its own handlers. No dynamic binding for necessary functions.
- Now the following properties of `ObsidianLiveSyncPlugin` belong to each service:
-`replicator` : `services.replicator` (still we can access `ObsidianLiveSyncPlugin.replicator` for the active replicator)
- A Handy class `UnresolvedErrorManager` has been added, which is responsible for managing unresolved errors and their handlers (we will see `unresolved errors` on a red-background-banner in the editor when they occur).
- This manager can be used to handle unresolved errors in a unified way, and it can also be used to display notifications or something when unresolved errors occur.
- property : service (still we can access these properties from `ObsidianLiveSyncPlugin` for better usability, but probably we should access these from services to clarify the dependencies)
- Please be aware that you have overridden createPouchDBInstance or something by dynamic binding; you should now override the createPouchDBInstance in the database service instead of using the module.
- You can refer to the `DirectFileManipulatorV2` for an example of how to override the createPouchDBInstance function in the database service.
**NOTE: Hidden File Sync and Customisation Sync may not work in this version.**
Just a heads-up: this is a patch version, which is essentially a beta release. Do not worry about the following memos, as they are indeed freaking us out. I trust that you have thought this was too large; you're right.
- Using `API.addCommand` or some Obsidian API and shimmer APIs, Many modules have been refactored to be derived to AbstractModule from AbstractObsidianModule, to clarify the dependencies. (we should make `app` usage clearer...)
- And I think that having a feature in modules directly is not good for maintainability, these should be separated to some module (loader) and implementation (not only service, but also independent something).
- Enabling this setting will restrict the propagation from the database to storage to only those changes made before the specified date and time.
- This feature is primarily intended for recovery purposes. After placing `redflag.md` in an empty vault and importing the Self-hosted LiveSync configuration, please perform this configuration, and then fetch the local database from the remote.
- This feature is useful when we want to prevent recent unwanted changes from being reflected in the local storage.
Also no behaviour changes or fixes in this release. Just refactoring for better maintainability. Thank you for your patience! I will address some of the reported issues soon.
However, this is not a minor refactoring, so please be careful. Let me know if you find any unexpected behaviour after this update.
### Refactored
- Rewrite the service's binding/handler assignment systems
- Removed loopholes that allowed traversal between services to clarify dependencies.
- Consolidated the hidden state-related state, the handler, and the addition of bindings to the handler into a single object.
- Currently, functions that can have handlers added implement either addHandler or setHandler directly on the function itself.
I understand there are differing opinions on this, but for now, this is how it stands.
- Services now possess a Context. Please ensure each platform has a class that inherits from ServiceContext.
- To permit services to be dynamically bound, the services themselves are now defined by interfaces.
Sorry for a small release! I would like to keep things moving along like this if possible. After all, the holidays seem to be starting soon. I will be doubled by my business until the 27th though, indeed.
### Fixed
- Now the conflict resolution dialogue shows correctly which device only has older APIs (#764).
- We can analyse the local database with the `Analyse database usage` command.
- This command makes a TSV-style report of the database usage, which can be pasted into spreadsheet applications.
- The report contains the number of unique chunks and shared chunks for each document revision.
- Unique chunks indicate the actual consumption.
- Shared chunks indicate the reference counts from other chunks with no consumption.
- We can find which notes or files are using large amounts of storage in the database. Or which notes cannot share chunks effectively.
- This command is useful when optimising the database size or investigating an unexpectedly large database size.
- We can reset the notification threshold and check the remote usage at once with the `Reset notification threshold and check the remote database usage` command.
- Commands are available from the Command Palette, or `Hatch` pane in the settings dialogue.
### Fixed
- Now the plug-in resets the remote size notification threshold after rebuild.
Now I am back from a short (?) break! Thank you all for your patience. (It is nothing major, but the first half of the year has finally come to an end).
