Extend search space for query searches about scope HOT 9 CLOSED

Resolved in b01b378
@kreftl I think we might have to change how something works, although I don't know what, to be able to get this working properly.

Locally, I had to add this to API.jsx (line 22-26)

'Clustering: Seurat resolution 2.0': {
    0: {type: '', value: ''},
    1: {type: '', value: ''},
    2: {type: '', value: ''}
},

and add a few sections for clusters in FeatureSearchBox (93-98)

} else if (response.featureType[i].startsWith('Clustering: ')) {
	clusters.push({
		"title": response.feature[i],
		"type": response.featureType[i]
		});
}

line 103

clusters = {"name": "clusters", "results": clusters.slice(0, 10)}

and lines 112-114

if (clusters['results'].length && (this.props.type == 'all' || this.props.type == 'clusters')) {
	res.push(clusters);
}

The problem is, it doesn't show Clustering: Seurat resolution 2.0' in the search box, and we would need a section in the frontend, specific to each clustering. I don't know how easy this would be to solve or whether the backend implementation could be altered to help.

Mind posting your thoughts?

from scope.

that for sure requires a change, let me investigate that in detail...

but is there a need to put Clustering: Seurat resolution 2.0 in the searchbox, or only e.g. cluster
and put the details of clusterings etc in some general page, e.g. proper dataset info ?

from scope.

My only thought there is that we were planning on being able to put multiple clusterings in the loom files (i.e. different resolutions in Seurat, resulting in more clusters), and in that case, some clusters from each clustering would have the same name, but some would be different. Also then we would have to somehow distinguish 'Unannotated' clusters from each clustering too.

Maybe we could have a way to select which clustering you want to search now I think about it

from scope.

i would use the cluster id somehow instead of putting the complete cluster name everytime
it will result in less data exchanged between the FE and BE
what about putting 'cluster#'+clusterID as a featureType ?

from scope.

That would work, but it would be nice for the user to be able to see the full description, think you can make that happen?
I will prep a new loom file soon, with a second clustering in it and hopefully the subclusters too

from scope.

the description anyhow comes in loom metadata, so i dont need to send it each time for feature query, there id only will be sufficient

how do we structure the subclusters ?

from scope.

Working on the subclusters, they are in the loom file now, but I need to decide if this is the most efficient way of putting them in there and then write the backend functions for you. Should be an update today (I hope!)

from scope.

depends on #56

from scope.

Old issue. Already implemented. Further enhancements will be tracked under new specific issues.

from scope.