public/owltide
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages 1 Wiki Activity Actions
owltide/plugins/payload-client-map.ts

44 lines
1.2 KiB
TypeScript
Raw Normal View History

License under AGPL version 3 or later I firmly believe in free software. The application I'm making here have capabilities that I've not seen in any system. It presents itself as an opportunity to collaborate on a tool that serves the people rather than corporations. Whose incentives are to help people rather, not make the most money. And whose terms ensure that these freedoms and incentives cannot be taken back or subverted. I license this software under the AGPL.
2025-06-30 18:58:24 +02:00
/*
SPDX-FileCopyrightText: © 2025 Hornwitser <code@hornwitser.no>
SPDX-License-Identifier: AGPL-3.0-or-later
*/
Refactor base types for entities and tombstones Rename the base Entity type to ApiEntity, and the base EntityToombstone to ApiTombstone to better reflect the reality that its only used in the API interface and that the client and server types uses its own base if any. Remove EntityLiving and pull EntityTombstone out of of the base entity type so that the types based on ApiEntity are always living entities and if it's possible for it to contain tombstone this will be explicitly told with the type including a union with ApiTombstone. Refactor the types of the ClientEntity and ClientMap to better reflect the types of the entities it stores and converts to/from.
2025-06-24 15:19:11 +02:00
import type { ApiEntity } from "~/shared/types/api";
Implement mutable mapping for client entities Create a simple Map like class for storing and keeping track of client entities that are synced from the server and have local editable state. This will form the basis for storing entities on the client and should replace the immutable concept used be the ClientSchedule class.
2025-06-23 00:03:37 +02:00
import { Info } from "~/shared/utils/luxon";
Refactor ClientSchedule to mutable types Use a single mutable location, event, slot, etc, for each unique resource that keeps track of the local editable client copy and the server copy of the data contained in it. This makes it much simpler to update these data structures as I can take advantage of the v-model bindings in Vue.js and work with the system instead of against it.
2025-06-23 22:46:39 +02:00
import { ClientEntity } from "~/utils/client-entity";
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
Refactor base types for entities and tombstones Rename the base Entity type to ApiEntity, and the base EntityToombstone to ApiTombstone to better reflect the reality that its only used in the API interface and that the client and server types uses its own base if any. Remove EntityLiving and pull EntityTombstone out of of the base entity type so that the types based on ApiEntity are always living entities and if it's possible for it to contain tombstone this will be explicitly told with the type including a union with ApiTombstone. Refactor the types of the ClientEntity and ClientMap to better reflect the types of the entities it stores and converts to/from.
2025-06-24 15:19:11 +02:00
const typeMap: Record<string, EntityClass<ApiEntity, ClientEntity<ApiEntity>>> = {
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
"user": ClientUser,
Refactor ClientSchedule to mutable types Use a single mutable location, event, slot, etc, for each unique resource that keeps track of the local editable client copy and the server copy of the data contained in it. This makes it much simpler to update these data structures as I can take advantage of the v-model bindings in Vue.js and work with the system instead of against it.
2025-06-23 22:46:39 +02:00
"schedule-location": ClientScheduleLocation,
"schedule-event": ClientScheduleEvent,
"schedule-role": ClientScheduleRole,
"schedule-shift": ClientScheduleShift,
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
};
const classMap = new Map(Object.entries(typeMap).map(([k, v]) => [v, k]));
Implement mutable mapping for client entities Create a simple Map like class for storing and keeping track of client entities that are synced from the server and have local editable state. This will form the basis for storing entities on the client and should replace the immutable concept used be the ClientSchedule class.
2025-06-23 00:03:37 +02:00
export default definePayloadPlugin(() => {
definePayloadReducer(
"ClientMap",
data => {
if (!(data instanceof ClientMap)) {
return;
}
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
const type = classMap.get(data.EntityClass)!;
Implement mutable mapping for client entities Create a simple Map like class for storing and keeping track of client entities that are synced from the server and have local editable state. This will form the basis for storing entities on the client and should replace the immutable concept used be the ClientSchedule class.
2025-06-23 00:03:37 +02:00
const accountStore = useAccountStore();
return {
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
type,
Implement mutable mapping for client entities Create a simple Map like class for storing and keeping track of client entities that are synced from the server and have local editable state. This will form the basis for storing entities on the client and should replace the immutable concept used be the ClientSchedule class.
2025-06-23 00:03:37 +02:00
timezone: accountStore.activeTimezone,
locale: accountStore.activeLocale,
api: data.toApi(false),
};
},
);
definePayloadReviver(
"ClientMap",
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
({ type, timezone, locale, api }) => {
const EntityClass = typeMap[type];
Implement mutable mapping for client entities Create a simple Map like class for storing and keeping track of client entities that are synced from the server and have local editable state. This will form the basis for storing entities on the client and should replace the immutable concept used be the ClientSchedule class.
2025-06-23 00:03:37 +02:00
const zone = Info.normalizeZone(timezone);
Remove type from Api serialisation of ClientMap Move the logic that converts the EntityClass of a map to a string and then back into the class to the payload plugin in order to avoid a circular dependency where the ClientMap needs to know the entity classes and the entity classes needs to know the ClientMap. The only place that doesn't know the type of the entities stored in the client map is the payload reviver, so it makes sense to keep this logic contained to the payload plugin.
2025-06-23 18:17:23 +02:00
return ClientMap.fromApi(EntityClass, api, { zone, locale })
Implement mutable mapping for client entities Create a simple Map like class for storing and keeping track of client entities that are synced from the server and have local editable state. This will form the basis for storing entities on the client and should replace the immutable concept used be the ClientSchedule class.
2025-06-23 00:03:37 +02:00
},
);
});
Reference in a new issue Copy permalink