Latent text content

I am currently working on a RDF/SPARQL editor.
The autocomplete allows to search for terms. On selection of a term, I would like to inject the URI into the text content but display a label at the place of the URI because these are potentially not very readable.
For example, the hidden URI https://www.wikidata.org/wiki/Q727 would have the label Amsterdam show instead.

The URI should be kept in the actual text content for parsing and executing of the query.
I am aware that this should probably use a StateField, AtomicRanges and Decorations but haven’t quite figured out how to do that yet.

Yes, setting up decorations, as in the decoration example sounds like what you want here.

Thank you! The example is using a MatchDecorator and ViewPlugin. How would I go about injecting this in the apply method of the autocomplete plugin?

@marijn Would you have any suggestions or code examples on how to implement this in an autocomplete setting. Would it require a transaction?

Every state change involves a transaction, so probably. But I don’t really know what you are trying to do here.

@marijn I basically want to build a Sparql editor that suggests entities in the autocomplete using their labels.
On selecting, I would like to insert the URI for that entity but show the label at its place rather than the unreadable URI.
Would appreciate any help!

And you want to do this replacement by label only for URIs that are completed, not those that are typed normally?

@marijn Those that are typed normally as well. So, I currently tried to do it using a MatchDecorator but I have to do an async call to get the label. I am currently hacking it into the toDOM function of the WidgetType but it obviously creates weird behaviour. What would be the right way to do this?

So then I guess integration with autocompletion is not actually what you need?

MatchDecorator assumes decorations can be created synchronously. Sounds like you’ll have to set up a custom view plugin that scans the document for URIs, fetches (and caches) their descriptions, and maintains decorations for the URIs it has a description for.

@marijn

Yes, that’s what I realized too.

Would you mind sharing a code skeleton with me? I don’t really know where to start to make the ViewPlugin work with async.

I’d do something like (assuming the labeling doesn’t change) keeping a global cache of known labels, and when initializing the plugin or when the document changes, scan view.visibleRanges for URIs (possibly using the syntax tree), and create decorations for the URIs you know the label for. For others (possibly in batch, to avoid trashing around when fetching a lot of labels on startup), start a request to fetch the label. When the response comes in, add the label to your cache, make the plugin recompute its decorations using the new cache, and force a view update with view.update([]).