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:
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:
The changes I proposed do not break backward compatibility, but only add new functionality.
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.
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.
The only difference between the clone and the original is the
definition.store.get()
/definition.store.set()
methods.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: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:
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.