Fork me on GitHub
#shadow-cljs
<
2021-06-03
>
Ronny Li02:06:48

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!

thheller06:06:12

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.

Ronny Li09:06:40

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."

Ronny Li09:06:33

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

thheller10:06:21

those two are completely separate and the HTTP server you use has nothing to do with hot-reloading. that is separate.

Ronny Li11:06:12

oooh gotcha so I'm supposed to run both at the same time. Thank you!

romdoq09:06:31

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.

romdoq10:06:50

okay, that's what I thought thanks 🙂

ikitommi11:06:38

is there a shadow + StoryBook example around there? the link in Clojureverse seems dead: https://github.com/shadow-cljs/examples/tree/master/cljs-storybook

thheller13:06:46

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

ikitommi18:06:17

might see more adoption if the integration would be that trivial?

ikitommi18:06:15

the example doesn’t work anymore:

TypeError: Cannot read property 'CLOSURE_UNCOMPILED_DEFINES' of undefined

thheller18:06:53

hmm yeah storybook changes a lot. kinda switches how everythingthing works every version. haven't looked at it recently.

rberger17:06:46

I for one would love a :target :storybook. Personally I think it would be a game changer in terms of making Clojurescript more popular.

thheller17:06:16

personally I'd much rather have some CLJS based. storybook doesn't look that special to me?

rberger17:06:36

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!

thheller17:06:06

looks fine for me from the config side. not sure what else :target :storybook could make easier?

thheller17:06:39

FWIW :target :npm-module also supports :ns-regexp "stories$" so you don't have to list all :entries manually

thheller17:06:16

{:target      :npm-module
 :ns-regexp   "stories$"
 :output-dir  "public/js/stories"}

rberger17:06:58

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"

thheller17:06:06

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

rberger17:06:06

Yes, will need to dive into it. Wish I had more time to explore meta tools for CLJS UI building. Maybe someday

myguidingstar17:06:10

what does it take to remove that constraint? I suppose it's connected to other part of the code base?

thheller17:06:09

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

thheller17:06:58

why do you care? I mean what files are you trying to load that aren't on the classpath?

myguidingstar17:06:00

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

myguidingstar17:06:08

currently lispy-mode can't work with shadow because it use cider to load the said cljs file when starting up lispy

myguidingstar17:06:48

and I see repl-load-file* thow exception that the file is not in class path

thheller17:06:59

hmm yeah thats a problem

myguidingstar17:06:24

so what does it take to fix? I suppose it may break the api or make some errors become uncaught?

thheller17:06:26

basically the same as the impl below that, just without all the classpath references

thheller17:06:24

will be kinda hard without understanding how all of it works internally 😛

myguidingstar10:06:40

this is hard indeed with all the internals 😄

thheller12:06:24

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

thheller12:06:17

I wanna look into something else first but I'll try to make a release later today

metal 2
myguidingstar14:06:58

great. Many thanks

thheller17:06:46

feel free to open an issue about this. can't get to it right now but maybe over the weekend

myguidingstar17:06:53

yes, I will. I'm trying to make a PR anyway...

myguidingstar17:06:43

thank you very much