Open kltm opened 1 year ago
just a quick thought @sierra-moxon @cmungall after yesterday's discussion about the schema, I realized the array/list might have minor performance issues because it is no longer a dict lookup and the consumer needs to do a search/find algorithms. an example below. However, if it is not a quick change schema, no worries,
1) The lookup type id always a key
This one getting a specific relation is a simple lookup O(1)
"relationships": {
"rel1": {
"medatada": ...,
},
"rel2": {
"metadata": ...,
}
}
getRelationship(rel) {
return relationships[rel]
}
2) List needs searching the whole list O(n) to find and prune to duplicate ids
"relationships": [
{
"id": "rel1",
"medatada": ...,
}, {
"id": "rel2",
"medatada": ...,
},
]
getRelationship(rel) {
for (let i = 0; i < relationships.length; i++) {
if (rel === relationshps[i].id) {
return relationships[i];
}
}
}
It might be a tiny loop, but the 2 way binding of client its been called multiple times
For "1" and "2", I would expect that the UI logic could unwind any data structure to a constant time lookup on load. I don't think the list is that long in the first place; I would be surprised if there was a lag there that a user would notice either way. Is this something you've noticed?
@kltm it hits hard. Unfortunately, it is not onLoad, but per binding lifecycle and since it is a form, it cycles a lot (textChange, blur, focus etc) . Preferably binding to constant lookup is desirable if possible than binding to function So everytime we want to display 'part_of' metadata we just get the value straight up
<p>{{MFnode.relationships['part_of'].metadata}}</>
Than do a loop
<p>{{getRelationships(MFNode, 'part_of').metadata}}</>
Then now it's for every relation and it refreshes per lifecycle detect changes.
Ah, that's interesting, and a bit nasty--too bad. Can you make global data structures in this case to take care of this overhead as the JSON should be invariant?
Once we have a draft schema in place from https://github.com/geneontology/go-shapes/issues/277, we need to hammer out the "final" schema that we'll be using for the ShEx transformation into useful products for applications.