Model instance methods (save, delete, etc?)

[JeffJassky]

I've been exploring ways to streamline interactions with model instances, particularly in the context of common operations like deleting or saving records.

Currently, we use a pattern like userRepo.destroy(user.id) or userRepo.save(user). However, adopting a more intuitive approach, like as user.destroy() or user.save(), could significantly improve developer experience by making the code more readable and easier to write.

Example problem:
Often, model instances are provided to a component via prop or some other reference. If that component needs to mutate the instance, the current method requires us to load an instance of the repository. Having direct access to save and destroy on the instance itself would greatly reduce boilerplate code of.

Current approach:
Note: the "user" is an instance of a UserModel, provided via prop, or other reference.

// boiler plate code needed to mutate any User instance
import { useRepo } from 'pinia-orm';
import UserModel from '/path/to/UserModel'
import UserRepo from '/path/to/UserRepo'
const userRepo = useRepo(UserModel)

user.name = 'Jeff'; // now user.$isDirty() is true
userRepo.save(user); // now user.$isDirty() is false

userRepo.destroy(user.id); // delete

Proposed Improvement:

// No boiler plate code needed to mutate the User instance, which was provided as a prop
user.name = 'Jeff'; // now user.$isDirty() is true
user.save() // now user.$isDirty() is false

user.destroy() // delete

It seems the code could be minimal such as:

class Repository {
	...
	saved(element){
		element.repo = this
	}
}

class Model {
	save(){
		if(this.repo){
			return this.repo.save(this)
		}else{
			throw new Error('Failed to save. Orphan model instance is not associated with a repository')
		}
	}

	destroy(){
		if(this.repo){
			return this.repo.destroy(this)
		}else{
			throw new Error('Failed to destroy. Orphan model instance is not associated with a repository')
		}
	}
}

While digging into the source code, I noticed that model instances don't have a direct reference to their repository, which is a barrier to implementing such instance methods directly. The model.$storeName() method could theoretically provide access to the underlying Pinia store, but direct manipulation of the Pinia state bypasses model hooks, leading to less maintainable code.

I'm interested in hearing the community's thoughts on this. Are there existing discussions or solutions I might have missed? How might we approach this enhancement while ensuring backward compatibility and maintaining the integrity of model hooks? Below are examples of the current and suggested approaches for comparison:

I believe this change could make our interactions with models more intuitive and fluent. I'm open to feedback, suggestions, and further discussions on this topic.

Thank you for considering my proposal.

[JeffJassky]

I've implemented a version of this using the following approach (warning: pseudocode)

PageRepo.ts:

import { useRepo } from 'pinia-orm'
import PageModel from './Page.model'
export class PagesRepository extends Repository<PageModel> {
	use = PagesModel
	...
}
export const usePagesRepo = () => useRepo(PagesRepository)

PageModel.ts:

import { usePageRepo } from './PageRepo.ts'
export default class PageModel extends BaseDocumentModel {
	static entity = 'Page';
	
	public save(){
		usePageRepo().save(this)
	}
	public destroy(){
		usePageRepo().destroy(this)
	}
}

I'm curious - is there anything particularly wrong with this approach? Circular references, memory use, etc... I'm still in the early stages of developing a new product and so haven't tested this at scale yet.

[CodeDredd]

Well what you trying to do is the way vuex-orm/core was written. I get your point.
But this is discussion between Apples and Oranges. Everyone likes something different more 😄 .

Your approach is correct. I wouldn't do it differently if i would like to have save, etc in the model. But i would all do this in a BaseModel so i don't have to write the functions again. I just don't know if that relly works and not causing parent to be executed all over. But i think it should be possible.,