This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (2)
- # beginners (83)
- # boot (472)
- # cider (10)
- # cljsrn (4)
- # clojure (80)
- # clojure-russia (7)
- # clojure-spec (34)
- # clojure-taiwan (1)
- # clojure-uk (7)
- # clojurescript (19)
- # core-async (5)
- # emacs (7)
- # figwheel (1)
- # hoplon (52)
- # jobs (1)
- # luminus (14)
- # om (1)
- # om-next (3)
- # perun (69)
- # proton (2)
- # protorepl (4)
- # re-frame (28)
- # reagent (6)
- # remote-jobs (1)
what should i see in the console/ui to indicate that something has happened due to reload?
When I was seeing reload failures, there were console errors about there not being a window object.
@micha about routes, is checking if the route is the right one before using route params the way to go? I found that problem at https://github.com/mynomoto/github-client/blob/master/src/github_client/page/exploration.cljs#L15
when used in that page are because you can be on other routes and the param is nil in that case.
@mynomoto i’m using bidi but i don’t re-use route-param keys across routes where it doesn’t mean the same thing
@thedavidmeister that sound restricting. I almost cannot believe that I didn't had this problem before but guarding against not being in the current route is a bummer 😕
I'm using silk for routes but it works almost the same as bidi so similar problems I guess.
They can but I was hopping for something less cumbersome than checking if it is the right route or if the param is not nil on every place where I want to use it.
usually if the functions return nil when they get nil arguments it just stops propagation naturally
Unless it causes a npe. In that case it was a keyword to get from a map and a string to run a regex on.
This solution has the advantage of not making code context aware as would check the right route would. Thanks.
@micha https://github.com/blog/2289-publishing-with-github-pages-now-as-easy-as-1-2-3 docs should be pretty easy now, aren't you already generating markdown files?
my docgen thing doesn't work with cljs though, because it uses reflection on the live system
would it be beneficial to organize core into smaller parts? It's starting to do a lot
i was thinking more like the protocols and such, they dont need to be in there but the implementations do
so i don't think we want to move any of those or it would break any code that uses a protocol method