Clojurians Log v2
cljdoc
My opinion: Unless you sense a very clear advantage of a search syntax, I'd avoid it, at least for initial versions.
I think lunr.js combined with mark.js is going to be a workable solution
But… if you decide some search syntax is warranted, lemme know! Would be nice to be consistent for libraries & docset search.
I think what's weird about the whole thing is that search for docsets needs to go beyond just full text and needs to include some atypical characters
for example with foo->bar as a function name if the person types exactly foo->bar then you'd want that to match over matching, say, a function named foo-bar. you typically don't match on non-word characters with full-text search
so tokenizing needs to be customized, as well as searching since if the user searches foo->bar we'd also want foo-bar in the list of matches just further down the list
and it gets even more sticky when it comes to the docstring searches since prose will also contain valid symbol characters that are not word characters except they will have different semantic meaning, they're not necessarily symbols
and this needs to be weighed against memory usage and search time
Interesting! Yeah, I see similar, but less complex issues for libraries search.
For the foo->bar situation, libraries search weighs an exact match on group/artifact very heavily so those will appear at the top. But it will also match items containing foo and bar.
For the free text prose in the library blurb, I’m not doing anything special/custom, but do see your concerns for docsets.
I am getting a little stumped with TypeScript and images 🧵
I’m experimenting with showing a wee clojars or maven-central icon in search results.
So I whipped up a couple of svg images and plunked them under resources/public
But have so far been unsuccessful in referencing them from search.tsx.
I do see parcel’s build plunking my svg in the expected spot:
resources-compiled/public/out/clojars.0eb7cf5b.svg 2.44 KB 327mssearch.tsx
import clojars from "../resources/public/clojars.svg";<img src={clojars}></img>Uncaught SyntaxError: import.meta may only appear in a modulecustom.d.ts file:
declare module "*.svg" {
const content: any;
export default content;
}I wonder @corasaurus-hex, what someone who actually knew TypeScript would do. simple_smile
This is probably very easy once you know what to do.
(this could also be more of parcel.js issue, dunno that tech well at all either).
can you try clojars.meta.url?
I think the static files stuff is misconfigured. I can look when I'm home but it'll be a while. in the meantime you could skip the import and just try "/dist/clojars.svg" or "/clojars.svg" or some other plain string in the image tag src
ok, I figured out what you need to do
stick the file in resources/public/static and it'll get copied over to resources-compiled/public/out
and then you can just refer to the path like
<img src="/file.svg" />I suspect you may also put it in resources/public and then import it but I'm not 100% sure
Thanks @corasaurus-hex very much appreciated! I was thinking the generated hashy filenames are important for... caching? So much to learn... If I'm not screwing things up by going the static route, I'm happy to do that.
yep, it's for caching
add a parcel.d.ts file in the root with:
declare module "*.svg" {
const src: string;
export default src;
}change this line in tsconfig.json
"include": ["js/**/*"]"include": ["js/**/*", "parcel.d.ts"]then you can do an import like
import cactus from "../resources/public/cactus.svg";<img src={cactus} />it'll use the hash as part of the filename and have the mtime as ms since epoch as the query string
this way if you change the file it'll change the url it hits
I can add that to main, actually
Thanks so much @corasaurus-hex! I did try the equivalent of your parcel.d.ts in a js/custom.d.ts(see thread above) and did not have success with that. But maybe I had a typo or something.... I'll try it again today. (I'll try your PR too).
I'm curious as to what is making a seemingly simple thing so awkward. Perhaps just my level of knowledge TypeScript and parcel.js.
And, I guess it is more about cache busting, yeah? A new filename gets generated for each release.
the main difference was yours had any for the default export type, it seems, but the working one needed string
but the whole "simple thing is super awkward" part is just javascript in general. the whole ecosystem is lumpy like that
Ah! I did not spot that difference, thank you!
And it stopped working. But moot point. I’ve abandoned the svg experiment for now because I found the icons more confusing than helpful (for the end-user of cljdoc). I am still super thankful for all your help!
hmmmm
ok
the clojure server proxies to the dev server?
I suppose any query language is bound to clash with the various characters allowed in symbols
Heya @corasaurus-hex, do you mean like allow searching for curse words? simple_smile But seriously… I’m not sure exactly what you are referring to yet. Maybe search syntax?
Maybe a comparison with libraries search will help?
The libraries search (which I am still working away at btw) offers no explicit syntax (you can contrast this with https://github.com/clojars/clojars-web/wiki/Search-Query-Syntax, I considered this, but I think we are doing the right thing for cljdoc).
Cljdoc libraries search finds libraries matching group-id, artifact-id and blurb (a shortened description, this refinement is a wip).
A library is scored (and sorted in results) by some factors:
• an exact match on group-id and/or artifact id should guarantee the match appears first in the list (refinements here are a current wip).
• we otherwise match text anywhere in a token (this is also a wip) so a search for corf will match seancorfield.
• libraries that are more popular will typically appear before the less popular ones (popularity (a wip) is via clojars download count over the last year or so).
• matches in the blurb are given much less weight than all other matches
I think (wip, tbd) I will also:
• as a rule, show any field we are searching in result (e.g. we’ll start showing the blurb)
• be highlighting matched search terms in result
right, the lucerne query syntax was what I was referring to, something like that
I undertook an effort to compare various client-side search libraries. it's all very spotty and uneven
i'm only part-way through the comparisons. I really like flexsearch but it doesn't have anything that highlights results