Now live: Searching within a single library now breaks down results for articles by section headings. Looking good to me, let us know if you see any issues! Thanks to @corasaurus-hex for encouraging me to dive in on this one (it is just a small change atop all the hard work done by her!).
is it worth crafting an announcement?
Well⦠there are rules for #announcements⦠and their frequency. But we can noisy as we like in #releases.
ahhh ok
I think(?) the rule of thumb was that if you can still see your #announcements announcement then donāt post a new one. But now that we have full Slack history⦠that rule no longer makes sense. simple_smile Canāt remember where this spelled out⦠somewhereā¦
Oh description on #announcements sez āPlease keep them occasionalā.
Iāll post the news in #releases
oof, tapping on mobile is broken because of loss of focus. i'll need to fix that
Good catch! And related: Would be interesting to know, some sort of usage stats. Like what percentage of folks come in from mobile.
gah, all search clicks are broken
oof
fixes it
@lee I'm just going to commit this to master so it ships quicker
⯠git diff HEAD
diff --git a/js/single-docset-search.tsx b/js/single-docset-search.tsx
index 7461755..81113ed 100644
--- a/js/single-docset-search.tsx
+++ b/js/single-docset-search.tsx
@@ -485,9 +485,6 @@ const SingleDocsetSearch = (props: { url: string }) => {
onBlur={(event: FocusEvent) => {
const input = event.target as HTMLInputElement;
input.classList.toggle("b--blue");
- if (showResults) {
- setShowResults(false);
- }
}}
onKeyDown={(event: KeyboardEvent) => {
const input = event.target as HTMLInputElement;
Sure!
can't believe I broke it š¬
Yeah, but the important thing is you noticed and you fixed it! š
pretty sure that fixes all the things
Awesome!
oof, type errors
maybe I'll do the work of rewriting these using functional components
oof, this is all tangled
Oof, if only I understood TypeScript! simple_smile Does that cause us problems? Can we catch these types of errors at build time and fail the build?
it doesn't right now but it's something we should fix
things are a bit tangled but it's nothing that can't be fixed
or put in the work to switch to cljs
I will defer to you on all things client-side, but I certainly would not object to a switch to cljs someday. That said, if TypeScript is a better fit and/or preferred, thatās absolutely cool too.
I'd like to learn some more cljs and it might be fun
I was also thinking we might be able to use sci to make it so certain libraries could be tried in the browser
Thereās an old https://github.com/cljdoc/cljdoc/issues/70 on this topic.
Iām also quite fascinated with https://github.com/nextjournal/clerk and wonder if/how it could integrate.
oooooh
big upvote here, rendering docs with clerk would be amazing
maybe a new doc format for this? allow people to include clerk files?
we'd have to be careful that nothing is automatically executed, that this is entirely opt-in
puts on her infosec hat
I definitely get a little anxiety at the thought of library publishers being able to run arbitrary javascript in a user's browser
specifically it potentially allows people to use the trust people have for cljdoc to ship malicious js without suspicion
The other thing we need to think of is stability and longevity. CommonMark and AsciiDoc are stable and safe and donāt change much. But other things do change.
Scary JS tidbit: it was only recently that cljdoc started sanitizing out embedded JavaScript from adoc and md š¬
yikes
Part of all that background maintenance work I was doing.
you're the real MVP, Lee
Bah, I donāt know about that! I like to help out here and there.