This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-03
Channels
- # announcements (1)
- # asami (13)
- # babashka (14)
- # beginners (58)
- # calva (49)
- # cljs-dev (6)
- # clojure (99)
- # clojure-europe (28)
- # clojure-gamedev (4)
- # clojure-nl (19)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojured (5)
- # clojurescript (39)
- # code-reviews (3)
- # conjure (4)
- # cryogen (12)
- # cursive (21)
- # data-science (4)
- # datalog (1)
- # datomic (16)
- # duct (4)
- # events (1)
- # fulcro (6)
- # graalvm (1)
- # graphql (1)
- # jobs (13)
- # jobs-discuss (23)
- # kaocha (2)
- # lsp (15)
- # malli (24)
- # missionary (6)
- # off-topic (21)
- # polylith (75)
- # releases (2)
- # remote-jobs (4)
- # shadow-cljs (47)
- # sql (35)
- # vim (10)
- # xtdb (4)
Hi everyone, does shadow-cljs handle URL rewriting to support deep-linking into a single-page app? We are hosted on firebase and to perform rewrites we just need to do the following (Note that we actually have two pages. Hopefully that's not an obstacle):
"rewrites": [
{
"source": "/",
"destination": "/index.html"
}, {
"source": "**",
"destination": "/trade.html"
}
]
So http://www.mysite.com/foo/bar rewrites to /trade.html on firebase but not in localhost. Any suggestions for how to fix this would be greatly appreciated!just use a the local firebase development http server. IIRC it has one? don't need to use the shadow-cljs http server for this.
Thanks for the the reply Thomas. My understanding is that the https://firebase.google.com/docs/hosting/test-preview-deploy#test-locally doesn't support hot reloading? Step 4 of https://firebase.google.com/docs/hosting/test-preview-deploy#test-locally says "To update the local URL with changes, refresh your browser."
but you're totally right that I'm able to test deep-linking when I use firebase emulators:start
as opposed to
shadow-cljs watch app
those two are completely separate and the HTTP server you use has nothing to do with hot-reloading. that is separate.
Is there a way to bundle eg. binary images along with an :npm-module
build? Such that I can get a URL to use in eg. an [:img {:src image-url}]
?
I'm thinking of something like the Webpack(?) bundler(?) that lets one import { default as myImageUrl } from './my-image.png';
in Javascript.
is there a shadow + StoryBook example around there? the link in Clojureverse seems dead: https://github.com/shadow-cljs/examples/tree/master/cljs-storybook
https://github.com/lilactown/storybook-cljs this is reasonably recent
there could be a :target :storybook
that outputs everything exactly in the format storybook wants but so far not too many people use storybook it seems
the example doesn’t work anymore:
TypeError: Cannot read property 'CLOSURE_UNCOMPILED_DEFINES' of undefined
hmm yeah storybook changes a lot. kinda switches how everythingthing works every version. haven't looked at it recently.
I for one would love a :target :storybook. Personally I think it would be a game changer in terms of making Clojurescript more popular.
Also @UAZRR3MRN wrote something up on his recent experience with it https://shaolang.github.io/posts/2021-02-14-storybook.js-with-shadow-cljs/
personally I'd much rather have some CLJS based. storybook doesn't look that special to me?
It's an ecosystem that would be nice to be part of. And there is no CLJS equivalent that I have found. Wish there were!
looks fine for me from the config side. not sure what else :target :storybook
could make easier?
FWIW :target :npm-module
also supports :ns-regexp "stories$"
so you don't have to list all :entries
manually
Well you suggested :target :storybook
😁 Sounded good to me. I have seen a few stabs at getting a minimal usage, I haven't had a chance to really dive into it yet.
But my interest is to use it as a way to document our internal UI Components and evolve to a design system. Ideally with the ability to leverage other things going on in the Storybook world (which may or may not really be possible if there are a lot of assumptions about having JS code be the main underlying "glue"
yeah but the blogpost you linked looks pretty optimal to me. not sure what else a :target :storybook
could do. there could be one if it was more complicated but it doesn't seem to be. I don't use storybook so no clue where the problems are
Yes, will need to dive into it. Wish I had more time to explore meta tools for CLJS UI building. Maybe someday
why is the file argument to load-file must be in classpath? https://github.com/thheller/shadow-cljs/blob/e6c7d36dc4a870c0b64286e0b590e69c06c63d43/src/main/shadow/cljs/repl.clj#L296
what does it take to remove that constraint? I suppose it's connected to other part of the code base?
because thats generally what you want for a "build tool", repeatable builds are the focus. so accessing stuff outside the classpath is generally not allowed
why do you care? I mean what files are you trying to load that aren't on the classpath?
I asked because I'm using lispy-mode in emacs (an alternate to paredit) which load some "middleware" which is just a cljs file packaged with lispy-mode itself
currently lispy-mode can't work with shadow because it use cider to load the said cljs file when starting up lispy
and I see repl-load-file*
thow exception that the file is not in class path
so what does it take to fix? I suppose it may break the api or make some errors become uncaught?
replacing this throw
with an impl that supports files outside the classpath https://github.com/thheller/shadow-cljs/blob/e6c7d36dc4a870c0b64286e0b590e69c06c63d43/src/main/shadow/cljs/repl.clj#L294
basically the same as the impl below that, just without all the classpath references
this is hard indeed with all the internals 😄
I went with a slightly different strategy so that it doesn't matter whether the file is on the classpath at all, no difference in code executed
great. Many thanks
feel free to open an issue about this. can't get to it right now but maybe over the weekend
yes, I will. I'm trying to make a PR anyway...
thank you very much