An issues-only repository for the Bryntum project management component suite which includes powerful Grid, Scheduler, Calendar, Kanban Task Board and Gantt chart components all built in pure JS / CSS / TypeScript
CRUD manager doesn't offer a convenient public API to override to load data from local objects. There is a public AjaxTransport, but it is expected to return object with Request interface - with status, headers, text method, etc.
At the moment there are few ways to intercept the fetch request sent by the CRUD manager:
Override AJAX helper to mock requests like we do in tests.
Implement the Transport layer. Transport layer receives a Request object which has to be converted to JS object first. And it should return Response object.
Intercept beforeSync event, start promise handling the data over the network and return false to cancel the sync request. This also requires user to manually apply all changes and commit them afterwards.
Another architectural issue to mention is that crud uses combination of promise and callback. Async flow was replaced with a promise chain starting from fetch but the old callback approach is still in place. This logic can be refactored to follow straightforward promise chain, handling errors.
Possible solution
Introduce a new layer for the CRUD manager which would receive and return message implementing CRUD protocol. This way it would be easier to replace with local data provider. It should be a layer, because we want to replace only the part which sends/receives the data, and we still want to invoke all the existing logic which handles responses and triggers events.
Use case 1
User cannot implement crud manager protocol on the backend (e.g. due to its distributed nature, or existing design), and the only way data can be provided is as JS objects, returned by some kind of client-side data provider (like wire service by Salesforce)
Use case 2
User can implement crud protocol on the backend but needs advanced network handling using some 3rd party provider like axios. Axios allows to have special handles for response status codes and provides means of authentication/authorization. Even though at this stage it is possible with CRUD failure callback, that would require duplicating logic rather than having it contained on a single level.
isglass
commented
2 years ago
Problem
CRUD manager doesn't offer a convenient public API to override to load data from local objects. There is a public AjaxTransport, but it is expected to return object with Request interface - with status, headers, text method, etc.
At the moment there are few ways to intercept the fetch request sent by the CRUD manager:
beforeSyncevent, start promise handling the data over the network and return false to cancel the sync request. This also requires user to manually apply all changes and commit them afterwards.Another architectural issue to mention is that crud uses combination of promise and callback. Async flow was replaced with a promise chain starting from
fetchbut the old callback approach is still in place. This logic can be refactored to follow straightforward promise chain, handling errors.Possible solution
Introduce a new layer for the CRUD manager which would receive and return message implementing CRUD protocol. This way it would be easier to replace with local data provider. It should be a layer, because we want to replace only the part which sends/receives the data, and we still want to invoke all the existing logic which handles responses and triggers events.
Use case 1
User cannot implement crud manager protocol on the backend (e.g. due to its distributed nature, or existing design), and the only way data can be provided is as JS objects, returned by some kind of client-side data provider (like wire service by Salesforce)
Use case 2
User can implement crud protocol on the backend but needs advanced network handling using some 3rd party provider like axios. Axios allows to have special handles for response status codes and provides means of authentication/authorization. Even though at this stage it is possible with CRUD failure callback, that would require duplicating logic rather than having it contained on a single level.