Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand the functionality of drafts #254

Open
Qsppl opened this issue Apr 22, 2024 · 0 comments
Open

Expand the functionality of drafts #254

Qsppl opened this issue Apr 22, 2024 · 0 comments

Comments

@Qsppl
Copy link
Contributor

Qsppl commented Apr 22, 2024

Let's say we have Model Definition A - DEFA.

Currently, when we create a draft Model Definition A (DEFA), we create a clone of Model Definition A (DEFA'') and then we we work with him.

image

The only difference between the clone and the original is the definition.store.get()/definition.store.set() methods.

const originDefinition = {
    [store.connect]: {
        get: // <userGetFunction>,
        set: // <userSetFunction>,
    }
}
const draftDefinition = {
    [store.connect]: {
        get: // <getFromMemory>,
        set: // <setIntoMemory>,
    }
}

If drafts are implemented so simply, then why restrict them? For example, we cannot create a list of drafts, although we could simply store them in memory in the same way as when using the definition.store.set() method. Or we cannot create a structure from nested drafts, although this also looks quite simple in this case.

We can simply copy the original definition structure and replace the methods definition.store.get(), definition.store.set(), definition.store.list() - then we can work with drafts in the same way as with conventional models:

image

In this case, each call to store(Definition, { draft: true }) will create its own copy of the original definitions structure.

To prevent this from wasting too many resources, instead of copying the entire definition structure, we can create drafts of related definitions as needed:

image

The changes I proposed do not break backward compatibility, but only add new functionality.

I was able to implement the suggested mechanics, but the rest of the store module code does not expect this behavior and errors occur, for example in this place: src\store.js:648

I have problems with further work on this feature - next I need to change the existing code of the store module in accordance with the new functionality, but for me this is too difficult.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant