This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-05-07
Channels
- # announcements (16)
- # asami (15)
- # babashka (12)
- # beginners (38)
- # calva (32)
- # cider (1)
- # clj-commons (9)
- # clj-otel (4)
- # clojure (57)
- # clojure-europe (43)
- # clojure-korea (1)
- # clojure-nl (1)
- # clojure-norway (13)
- # clojure-uk (4)
- # clojuredesign-podcast (9)
- # clojurescript (10)
- # cursive (5)
- # datahike (9)
- # deps-new (2)
- # events (1)
- # fulcro (8)
- # hyperfiddle (7)
- # kaocha (1)
- # lsp (2)
- # malli (3)
- # nrepl (2)
- # off-topic (19)
- # releases (3)
- # ring (10)
- # shadow-cljs (4)
- # sql (14)
- # xtdb (57)
- # yamlscript (2)
I'm using goog.history.Html5History
and am confused by the method names .getToken
, .setToken
, and .replaceToken
. Why "token"? The methods seem to return and set the current href
but why are they not then called something with href
or URL
or similar?
It might be something other than the URL since there's a way to convert between tokens and URLs which you can adjust by using setPathPrefix
or specifying a transformer. Note also that the query isn't a part of the token as well.
All follows from the implementation of getUrl_
:
goog.history.Html5History.prototype.getUrl_ = function(token) {
'use strict';
if (this.useFragment_) {
return '#' + token;
} else {
return this.transformer_ ?
this.transformer_.createUrl(
token, this.pathPrefix_, this.window_.location) :
this.pathPrefix_ + token + this.window_.location.search;
}
}
Ok. So the token may be some internal representation of a browsing target?
So I’ve been looking into the pros and cons of different routing libraries, reading articles like this one: https://ericnormand.me/mini-guide/clojure-routers
And this sentence stood out to me: > If you’re doing both frontend and backend, you want to be able to share the routes between them. Having the same code work on the server and the client might be useful. Why would a web app want to share routes between BE and FE if everything’s a SPA, or at least doesn’t share a 1-on-1 correspondence between FE browser URLs and BE REST endpoints, these days (and haven’t for over a quarter century)?
So that you don't have to define your API endpoints both sides. Define it one place, implement it on the server-side, use the routes for (API call) URL generation on the frontend
Also works if the server for example sends emails that should contain the user-facing UI URLs
I suppose that would be useful for some contexts, just not every single context (e.g. if your app uses GraphQL and is served using a single endpoint for the BE)
Has worked great for me. Reitit API routes are in a .cljc
file and the front end does requests to route names instead of URL strings.