Backend-for-Montage support - #1979
Conversation
- adds a convenience method to get a DataService instance from the module
DataService organized into the following - Snapshotting - Service Hierarchy - Mappings - Model - Data Triggers - Data Object Properties - Data Object Creation - Data Object Changes - Fetching Data - Saving Data - Offline - Utilities
# Conflicts: # data/service/data-service.js # data/service/raw-data-service.js # test/all.js
|
Karma test with |
|
The values in Further, in order for them to be identifiable with equality in memory, it would need to be a proper class instead of a POJO. Then the check is as simple as UPDATE Each OperationType is added to the exports for {
"operationType_Read": {
"object": "montage/data/service/data-operation[ReadOperationType]"
},
"root": {
"prototype": "montage/data/service/data-operation",
"values": {
"type": {"@": "operationType_Read"}
}
}
} |
Refactor and build out Montage Data to enable "Sentinel" project.
This branch is the consolidation of the following branches:
https://github.com/montagejs/montage/tree/features/raw-data-worker
https://github.com/montagejs/montage/tree/tej/features/data-service-mapping
https://github.com/marchant/montage/tree/data-operation-evolution
This PR encapsulates the following functionality:
RawDataWorker Receives DataOperation objects and lazily initializes RawDataServices designed to handle those DataOperations.
DataService Mapping Move responsibility for mapping of raw data to cooked objects and vice versa into DataService. This allows a single DataService to handle all of the data for an application without maintaining the full RawDataService tree. It follows that RawDataServices (and the responsibility to fetch data from the origin) can move off the client.
DataOperation refactor Build out DataOperation API to normalize the way data travels up and down the stack.