This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-11
Channels
- # announcements (3)
- # asami (4)
- # babashka (79)
- # babashka-sci-dev (47)
- # beginners (97)
- # biff (12)
- # calva (7)
- # clj-commons (3)
- # clj-kondo (22)
- # clj-on-windows (13)
- # cljdoc (31)
- # cljfx (2)
- # cljs-dev (1)
- # clojure (85)
- # clojure-austin (4)
- # clojure-dev (12)
- # clojure-europe (15)
- # clojure-italy (8)
- # clojure-nl (4)
- # clojure-uk (4)
- # community-development (19)
- # conjure (3)
- # core-typed (40)
- # cursive (9)
- # datahike (21)
- # datomic (1)
- # emacs (7)
- # exercism (2)
- # graalvm (20)
- # graphql (1)
- # honeysql (16)
- # jobs (1)
- # malli (2)
- # off-topic (3)
- # pathom (28)
- # pedestal (3)
- # polylith (7)
- # reitit (14)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (4)
- # shadow-cljs (21)
- # sql (21)
- # testing (8)
- # tools-deps (23)
- # vscode (8)
- # xtdb (38)
Hi! Is it possible to host a private documentation for the companies project? I love cljdoc documentation and things but as I found so far, it only offers for public.
Hi @U02SKL96W1J! To host private docs you’d have to setup your own cljdoc server at your company. This is certainly possible but not trivial.
very much an aside but part of this search work has me pulling functionality out of request handlers and making them available as functions. ideally, for me, request handlers should be doing as little as possible such that they only contain the things that are specific to http request handling
you can see the two parts I pulled out in that file
so things like extracting parameters, loading things from the config, etc, can be in the handler but there are only one or two function calls. that way the request handling details are decoupled from the functionality
I've noticed this a lot in clojure projects, fwiw. there doesn't seem to be much of a sense of where to separate things within request handlers. in ruby, at least, there's a strong focus on request handlers being as simple as possible
in the rails world they have a phrase for it: "fat model, skinny controller"
but really it's about separation of concerns and making code as re-usable as possible
I think in a functional world that's even more important since we can compose functions so easily it makes re-use even more valuable
my thoughts aren't 100% fully formed but I thought I'd share
absolutely
maybe we should split single docset search from finding functions/namespaces by name
I'm having such a hard time getting the search to work like I'd expect
lunr offers highlighting but the search isn't as good. flexsearch has fantastic search but no highlighting
wat do
really, funding the right function/namespace could be like a fuzzy finder with some levenshtein distance checks, but searching docs is more of a full-text search problem
and I think this is why I'm struggling
think of it like searching a project on github vs hitting t
and doing fuzzy file finding
I’m not sure what kind of sophistication cljdoc users would be expecting. They’ll probably be very happy with whatever first cut you come up with! Maybe if you tokenize in such a way that both words and symbols can be found, you might have a good first cut?
that's the thing, they're not terribly configurable
i'll need to play around more
(this is in the theme of libraries search work and the idea you should see the freetext content that you are searching)
it could use some spacing and increase in font size, I think
maybe put clojars on the same line as the version and move view docs down beneath it
it's pretty sweet
I like that I can see the description