Fork me on GitHub

@dnolen: offhand question before I go to sleep - any reason why :require wouldn't work with module$react_tap_event_plugin$index but would work with module$reacttapeeventplugin$index? I'm not yet 100% sure but somehow underscores seem to mess up requiring the converted modules.


@jaen I can’t think of anything off the top of my head


@dnolen: what should I be looking at to understand that? cljs.analyzer/analyze-deps or something else? Right now I'll try to work around this with some dumb renaming, but it probably will be something that have to be dealt with at some point (that, or getting GClosure to let me decide what module name will be during conversion).


@jaen I would just look at what JS got generated


look for the goog.require


@dnolen: The require is in the generated module (I also put it under path reflecting the module name); GClosure module conversion generates module names like module$react$react (in case of react for example). I can require that as (:require [module$react$react :as React] no problem. But when I have a library with dashes in name, like react-event-tap-plugin I end up with module name like module$react_tap_event_plugin$index and Clojurescript compiler can't seem to find it. But when I edit the the module to not have underscores in name it starts working. That why I suspect Clojurescript treats underscores in some special way (or I'm misusing something).


@jaen: hrm I don’t think so, dashes are treated specially, they get converted into underscores


@jaen fwiw this is where Cursive debugging becomes really useful, you can set a breakpoint in ClojureScript where the error is happening and poke around


in your own project


Yeah, having debugging support in Cursive is godsend; it's probably something I'll try after I get some sleep. Though maybe that symptom might have some obvious causes (like me misusing something), hence the question.


@dnolen: by the by, if you could point me what parts of the compiler are responsible for resolving the references in :require to files on disk it would be appreciated; that could be a good hook to start understanding what's happening


@jaen: cljs.analyzer/analyze-deps is where it happens at compile time


for runtime we need to build deps.js which builds the whole graph


REPLs modify this so that Google Closure can resolve during dev


And in cljs.analyzer/analyze-deps this fragment here (deps/find-classpath-lib dep) is responsible for loading the dep from the source given the symbol, do I get that right?


that’s one kind of library that attempts to get resolved yes


JS libs that aren’t actually going to be analyzed but existence confirmed


I see. And when I have a goog.provide with module$react_tap_event_plugin$index should I be using module$react_tap_event_plugin$index or rather module.react-tap-event-plugin.index with :require? I assume the former, since I need to match the module name in goog.provide, but now that I look at find-classpath-lib it only transforms . -> / and - -> _, so $ will stay as-is, so this might be part of my problem.


Is there a relatively widespread template for server-side cljs rendering? either nashorn or node


Hi everyone, is there a way to add another .js output in cljsbuild? for example one dedicated to compile 'only' one .cljs file; the reason being that I want to use that separate generated .js file as a Web Worker.


@dnolen @maria: some more (dubious) progress - material-ui seems to be working. I say dubious because notice how atrocious the code looks (especially the way I have to handle module$material-ui$styles$theme-manager, which is a module returning a function [constructor to be more precise], where :import won't work since it expects dots not dollar signs in name). But at least it proves that it's somehow possible to get Clojurescript to handle those modules. Now I'll just have to talk with GClosure people on how they best suggest solving the mess with requires and module names and this might even start looking not so bad.


Novice question: what’s the best way to do route navigation in ClojureScript? Does it just boil down to using links with fragments, or is there another way? I’m just getting started with an Om application and I’m finding my links fully reload the page, which is obviously something I want to avoid.


unfortunately only that blog post really answers my question


and even that’s doing links with fragments


@masonbrowne: Doing the smae thing re: sneaking in simple_smile


I threw something together from gists and various blog posts that does what I want


Figure it might be valuable to someone else


@venantius: I realise I'm too late, but: I usually cannibalise this - - with some modifications, but your solution is certainly simpler.


@dnolen @maria and whomever it may concern - so I have actually gotten raw React, material-ui, react-motion and their assorted dependencies working. Required actually forking GClosure to add support for custom module loaders (half-baked ATM) so I will be able to influence resulting module naming and their resolution during conversion. You can clone the repo and run ./ to see that it actually works -


@jaen: yep, that was one of the first places I looked, but it looked like a ton of code to grok


@amithgeorge: I thought so too but i found the docs a bit confusing


Now that I've actually written the thing pushy is basically what I wanted :p


@venantius: right, this is quite a bit of parentheses to chew on; I only mostly understand what's it doing, maybe I should have gone your route and write it up from scrach


@jaen: well next time you can just use Accountant! :)


Then you'd probably get a pull request for it to support bidi ; d


But I guess something that's readily understandable is better than CircleCI's monolith