Can anyone link/help me integrate google signin in clojurescript

hey @sam16 pls try this https://developers.google.com/identity/sign-in/web/reference

Can someone share a snippet in cljs if possible

hey, https://github.com/material-components/material-components-web uses an npm package name of @material. This produces import errors. Is there any workaround for this?

.. besides prepackaging it with webpack ...

@bendlas are you using the :npm-deps feature?

exactly

right now, I've reverted to using the precompiled bundle, they provide, but I'd like to import it directly

the unusual @material identifier seems to get in the way, @dominicm

@bendlas so if this were js you'd do require('@material')? 😱

not sure if that's a failure in clojurescript or in google closure

Hmm :thinking_face:

What does your :npm-deps look like?

yes, rather `require('@material/card') or something

`

@bendlas Oh, gotcha. npm-deps should be fine then. How does your cljs :require look?

:install-deps         true
                                    :npm-deps             {:material-components-web "0.17.0"}

I've tried [@material.card], ["@material.card"] as well as ["@material/card"]

I suspect it's a gclosure fail, since you can also require [material-components-web], then the transitive require for @material modules fails too

if the npm dep is material-components-web, then the only entry point is that - so it would have to be something like (:require [material-components-web :as material])

@sundarj exactly. That fails

ah, i see

it fails because of transitive dependencies to @material modules

right, gotcha

@bendlas did you mean ["@material/card" :as card]?

or maybe it's "material-components-web/@material/card" :thinking_face:

@dominicm I've tried the first one, nope @ second one. see https://unpkg.com/[email protected]/index.js

ah, looks like material-components-web actually depends on "@material" or something

it does

not that it will fix your issues, but you should use the exact same name you would use in Node.js when requiring. In the case where it would not be a valid symbol or it would be munged, use string require

@dnolen i figured that. seems like closure is at fault. I'll try with the latest version and maybe report a bug ..

not necessarily, this is all brand new stuff

we’re doing far more with it than anyone else using Closure Compiler far as I can tell

and we’re pushing it faster with patches etc.

when you say “import errors” I’m assuming Closure says it’s couldn’t import some module

but all that means is that it couldn’t find it

and it couldn’t find it because we didn’t pass it in

right, I'm not quite sure about who does what about npm deps between cljs and gclosure. the transitive modules showed up in <root>/node_modules but not in <cljs-out>/node_modules

so those deps weren’t found by us

you may want to try your project with master

will do

OK, so the error with cljs master is the same: 1) when requiring something like ["@material/card" :as mc], the analyzer fails with No such namespace: @material/card, could not locate _CIRCA_material_SLASH_card.cljs, _CIRCA_material_SLASH_card.cljc, or JavaScript source providing "@material/card" 2) when requiring the parent namespace [material-components-web :as mcw], it compiles but gclosure can't find the sources: `Uncaught Error: Undefined nameToPath for module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$temporary at visitNode (base.js:1357) at visitNode (base.js:1355) at visitNode (base.js:1355) at visitNode (base.js:1355) at visitNode (base.js:1355) at Object.goog.writeScripts_ (base.js:1369) at Object.goog.require (base.js:706) at (index):15`

@dnolen @dominicm @sundarj

@dnolen can confirm, but I suspect cljs might not package up transitive dependencies for google closure.

Hmm, maybe not actually, given the failure in 2.

@dominicm that’s not accurate

we handle transitive deps

the reasons this might not be working are many

is the second dollar sign in node_modules$$material a munged @, or is that always there?

that’s just a Closure generated module name

sure

@bendlas oh but I think I know what might be happening, we only index the top level

if your code is trying to require a transitive dep that isn’t going to work and we don’t support that

you need to express an explicit dep on anything you want to bring in

ok, that explains #1 right?

(actually I don’t know if that’s the problem here, but it’s something to check)

I don’t know

funnily: cljs_deps.js contains paths like goog.addDependency("../node_modules/@material/base/foundation.js", ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$base$foundation'], []);

fix your deps and check 🙂

@bendlas well those are relative urls, but what’s there in your :output-dir?

@dnolen as opposed when I checked before, the output folder now contains node_modules/@material

then I don’t think there’s anything weird here

but there is stuff missing

that’s a different problem

do I need to list all that in :npm-deps?

that always means something didn’t get resolved

@bendlas if the lib you want to require is not in the dep, it’s not going to work

that’s the rule

but it is in the dep

then there’s something wrong 🙂

and I don’t have any ideas about that

I’m just removing the random guessing about how this is supposed to work 😉

Looking through the https://github.com/material-components/material-components-web package.json, I can't actually see @material/card or anything like it.

@dnolen so the current failure is that none of the subdirs of @material/drawer get included: https://unpkg.com/@material/[email protected]

@dominicm https://github.com/material-components/material-components-web/blob/master/packages/mdc-card/package.json

@bendlas why should they get included?

https://github.com/material-components/material-components-web/blob/master/packages/material-components-web/package.json here's the master package.json, my bad 🙂

@dnolen because in the index.js, there is are lines like: export {MDCTemporaryDrawer, MDCTemporaryDrawerFoundation} from './temporary'

(I’m asking what would trigger them to get included?)

I mean in your project

we don’t randomly copy everything over

only stuff we see that you need

so I do need to list all my transitive deps?

no

I’m asking a very simple question

what depends on drawer?

card?

material-components-web does for one.

@dnolen the top-level index.js does: goog.addDependency("../node_modules/material-components-web/index.js", ['module$home$herwig$checkout$diagnosia_app$node_modules$material_components_web$index'], ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$auto_init$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$base$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$checkbox$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$dialog$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$form_field$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$grid_list$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$icon_toggle$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$linear_progress$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$menu$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$radio$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$ripple$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$select$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$slider$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$snackbar$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$tabs$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$textfield$index', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$toolbar$index']);

(:require ["@material/card"]) can't even be analyzed.

The weird thing is, drawer depends on it's subdirs: goog.addDependency("../node_modules/@material/drawer/index.js", ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$index'], ['module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$util', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$temporary', 'module$home$herwig$checkout$diagnosia_app$node_modules$$material$drawer$persistent']);

but those aren't there in cljs_deps

so it seems that it indexes modules within the same directory, but subdirectories are ignored @dnolen

@bendlas https://github.com/material-components/material-components-web/tree/master/packages/mdc-card, side note, let’s paste snippets to avoid flooding the channel like that

I don’t see any JS at all under this package

yes, sorry.

@bendlas there’s no JS under drawer either

so of course there’s isn’t going to be anything

there is: https://github.com/material-components/material-components-web/tree/master/packages/mdc-drawer

oops sorry missed that, was only looking at permanent

but yeah, many @material packages just have .scss files. I was going to figure out the appropriate babel transform later

@bendlas playing around with this over here

great! I can revisit this later, when I'm not on company time. for now, I'll just use the prepackaged version.

thanks!

Antonió could provide some insight later when he’s on as well - I’m pretty sure someone else had tried material and they had gotten further

@bendlas I can repro your issue here, it just seems we’re not properly computing the node_modules inputs that must be passed through Closure in this case

hello \o/ is there a canonical simple cljs library people like to use for using localStorage?

@daiyi I would probably just look to see if Google Closure has something first

oh good idea, thanks!

(I should make a better habit of looking into goog closure)

@daiyi I think Closure lib has something, but you can also check https://github.com/alandipert/storage-atom which hides localStorage behind an atom (not sure if good idea) and takes care of encoding/decoding using Transit

https://google.github.io/closure-library/api/goog.storage.Storage.html

@dnolen thanks for digging into the issue. let me know, if you could use any help with the ticket

https://google.github.io/closure-library/api/goog.storage.mechanism.HTML5WebStorage.html

storage-atom is pretty nice. You can use with add-watch

@daiyi there’s a bunch of mechanisms

depending on what you’re doing storage-atom might also work for you - but I’m generally loathe to take on dependencies for basic stuff like this

the affordances often aren’t worth the trouble - but your mileage may vary - and it’s really depends on the project

for something serious I would not take on a dep - for fun - sure

@bendlas well if you’re curious I believe the issue has to be with module_deps.js

we have a Node.js script that compute the set of inputs we need to pass to Closure

Hi! I need to make simple jquery callback after a component is rendered. How can I specify that function name as an extern before running lein cljsbuild once min? Grateful for any pointers.

I did feel like it's quite a simple task that probably doesn't need dependencies. I'll start with google closure, thank you!

@daiyi it’s also just nice to get familiar with Google Closure Library - it’s really a treasure trove

once you wrap your head around you realize there’s just so many cases where you don’t need third party JS dep

or a CLJS dep

I've noticed lots of advanced clojurescript people using it very often, so I suspect it's a power I should unlock :D I'm surprised not more javascript people use it

@daiyi it’s not straightforward to consume for JS people because it’s a module convention that predates modern JS and is somewhat conceptually at odds

everything is global, scope is managed via ubiquitous namespacing

ah, people don't like that anymore

this definitely is at odds with JS conventions

however it’s awesome for a Lisp like ClojureScript

hot-loading is trivial

it’s also not difficult to rewrite JS into Closure style, that’s how all this new fancy node_modules stuff works

@bendlas I think I see the problem export ... from JS pattern doesn’t seem to get picked up?

in index.js for drawer I see the util import works but not the 2 export ... from at the bottom of the file.

yeah it seems Closure does the right thing with export ... from statements, but those deps aren’t getting passed in as inputs

the issue is looking more and more like module_deps.js

@dnolen right, i wasn't sure whether this was bc if export .. from or because of subdirs ...

subdirs not an issue

we have scoped package resolution in module_dep.js

the problem is konan

we use that to understand import when collecting inputs, but konan doesn’t appear to support export ... from

Hmm. I tried to switch from ClojureScript 1.9.521 to 1.9.854 and I get:

#error {
 :cause com.google.protobuf.GeneratedMessageV3
 :via
 [{:type clojure.lang.Compiler$CompilerException
   :message java.lang.NoClassDefFoundError: com/google/protobuf/GeneratedMessageV3, compiling:(cljs/closure.clj:210:3)
   :at [clojure.lang.Compiler analyzeSeq Compiler.java 6926]}
  {:type java.lang.NoClassDefFoundError
   :message com/google/protobuf/GeneratedMessageV3
   :at [java.lang.ClassLoader defineClass1 ClassLoader.java -2]}
  {:type java.lang.ClassNotFoundException
   :message com.google.protobuf.GeneratedMessageV3
   :at [java.net.URLClassLoader$1 run URLClassLoader.java 372]}]

@jrychter dependency issues

something is clashing

(I’m referring to JVM deps)

likely something is overriding a dep Closure Compiler needs

@bendlas yep I just repro’d the problem with konan

So .. @dnolen stands for Detective Nolen, right?

😉

Ok, I'll try staring really hard at lein deps…

@jrychter no need lein deps :tree

it will list conflicts

@dnolen That's actually what I meant. And it does suggest considering "[org.clojure/clojurescript "1.9.854" :exclusions [com.google.protobuf/protobuf-java]]".

Which is actually not what I want

look at what else needs protobuf-java that isn’t ClojureScript transitive

I think I found it. Two packages: bouncer, which requires an older version of ClojureScript, and clj-rethinkdb, which uses protobuf-java 3.0.0-alpha-3.1 directly. I'll add an exclude to clj-rethinkdb.

@dnolen Yep, that did it. I'll work with clj-rethinkdb to update their protobuf-java version. Thanks for the help!

np

@dnolen I'll report to https://github.com/egoist/konan/issues, unless you're already on it ...

https://dev.clojure.org/jira/browse/CLJS-2325

@bendlas not worth it IMO

would prefer to get out of Node.js dependency silliness

right, I'll report it anyway, even if we stop using it

just out of courtesy

makes sense

not sure why we needed ecmascript modules in javascript, i am personally not a fan 😞 we could've had better number types or better data structures. instead we have async module load.

@ashnur for the same reason we need to suport .jars in Clojure. Interopability. If you don't need it, good for you.

there have been many people in the community, welcoming this with teary eyes

yes, lack of JS modules was a huge problem

Just a heads-up with cljs master, I get async.cljs?rel=1502892032791:13 Uncaught TypeError: goog.net.jsloader.load is not a function @bhauman

@bendlas pretty sure @tony.kay saw the same thing - Figwheel doesn’t seem to work with :modules

unlikely to delay a release just for Figwheel and this feature though

if somebody can come up with a theory why it doesn’t work I’ll take a look at - but I’m not going to do any initial research myself - this release has been delayed too long already

@dnolen I'm not using :modules. Neither npm ones, nor closure ones. I wasn't suggesting to delay either, but I'd love for figwheel to fix this asap. Looks like one of the removed closure namespaces to me

Does latest Cljs update Closure-library?

@juhoteperi it did yes, you can always downgrade it manually though

@bendlas oops sorry, I thought that was something to do with cljs.loader

Okay, probably Fighweel needs to start using safeLoad instead of removed load. Boot-reload has the same problem.

@juhoteperi yep: https://github.com/google/closure-library/commit/988ff900886e959a888485ee56d1540d1bf2f29d

load has been deprecated for ages, I think, but we haven't seen deprecation warnings so there will be some broken code

Maybe because Closure only shows warnings when doing advanced build and figwheel nor boot-reload are not used in that case

@dominicm @sundarj @bendlas I'm glad David ended up finding your issue. I'll get to it soon, but will probably not be in today's release. Just a side note: it doesn't help very much coming up with theories based on random guessing for why things don't work. In fact, we do index the entire node_modules installation (we just don't descend into nested node_modules/pkg/node_modules). We do support requires of the form @foo/bar/baz and whatever form you can think of (like collapsing x/index.js to x, etc.

@anmonteiro thanks! I try to avoid random guesses. My first theory about the @ being the problem turned out to be false, but it was based on my not seeing the folder in the output directory (for whatever reason)

Something that I find very useful when looking at things like this is to consult the tests

And we do have a bunch of tests in CLJS for all this

yeah, I get that false starts like this are frustrating from a maintainer's perspective, I have been on that side as well, but there really wasn't that much random guessing involved. I'll try to do better though. Looking at tests when diagnosing is probably a good idea.

@bendlas in particular for :npm-deps

it just spreads confusion at this stage to guess 🙂

@bendlas & others I reported the jsloader problem on figwheel with details (https://github.com/bhauman/lein-figwheel/issues/594) and pushed a new snapshot of Boot-reload with the fix

well, yeah. I tried to be more specific than "library x doesn't work" and the guess wasn't random, but I'll try to describe the actual situation, next time @dnolen @anmonteiro

@juhoteperi thanks for the heads up

[offtopic] https://github.com/GoogleChrome/puppeteer

can i give multiple directories to cljs.build.api/build ?

or do i need to use :libs ?

@bbloom Directories that contain cljs sources? cljs.build.api/inputs

gotcha - will try that, thx

@bbloom But ClojureScript also looks for sources in classpath, if I recall correctly, only the directory which contains :main ns needs to be in inputs

de-lurking for a moment: very glad to see that all the Cool Kids are here, now that I’ve taken up a clojure/cljs job. 😄

hey brian - nice to see you here 🙂

thanks! you too 🙂

i haven’t been writing much cljs lately - just trying to help fix a fipp bug somebody reported

@bendlas I have no problem with “library X doesn’t work”. the problem here was guessing that could cause misinformation to newcomers or other people looking to try out this feature

anyway, I think you get my point and nothing constructive is going to come out of this

you know, if I had a wishlist for cljs/om, it’d be something like Rx. But I’ve been on an Rx kick for a few years now.

what do you need out of rx? i’ve found it to be a pretty painful model to work with in practice

i even wrote an rx-like with cljs & decided “this is a bad idea” and i know a core contributor to microsoft’s original rx 🙂

aww

i bet we can find you an alternative that meets your needs 🙂

what made it feel wrong?

for servers/etc, the default is a lack of back pressure

yeah, that’s what I’d like to hear; what suffices that need. Om or bare react misses some things.

but more generally, it’s a model built on incorporating time in to sequences - which is an unnecessary complication

you can add trasducers to channels, which means that all transformation remains synchronous - you can handle time with other mechanisms

yeah, except when time matters!

in that case, i’ve found a queue to work much better

can I write a continuous abstraction over time that composes?

no, but then again, i’m not sure you really want to 🙂

maybe a state-machine composition…

let’s make it concrete & i can explain my thinking - do you have an example?

oh, man, see, that’s where people start discounting user requirements in my experience.

of what you’re trying to do where rx would help?

not right this second; still on day 8 of the new job.

feel free to @ me when you do, happy to help explore alternatives

last job was react/redux and I really needed to throttle and debounce non-UI stuff quite a lot, and use mediated/programmatic throttling.

for high-volume interactive data-viz where the frontend had to do a lot of the crunching.

PureScript was the “preferred fancy UI language” but it did not meet my needs.

not sure i follow - what were you debouncing? server sent events?

aggregations were map/reduce jobs and the UI had to perform a streaming reduce

redux-saga was the presumed performer for a lot of work in that area but the team was too uncomfortable with both that and Rx.

a streaming reduce over what?

each DB shard would perform its own agg and send its results.

or … partition, really.

eh, this is too much right now. I’d be happier to hear about effect types in dynamic languages, if you’re still on that @bbloom.

heh, sorry

@juhoteperi @dnolen I just pushed the fix for the jsloader deprecation

@bendlas ^

@juhoteperi I'm changing my fix so that it's backward compatible, the current fix is only good for CLJS >= 1.9.223

thats a bit narrow and will definitely cause problems for folks

@bhauman Ah, good catch, I'll copy the fix to boot-reload 🙂

🙂

@juhoteperi updated it https://github.com/bhauman/lein-figwheel/commit/9e8e6d4504c807f8a41767075bf86cbab67df6d1

checking to see that 1.9.908 works

in figwheel

good stuff cljs 1.9.908 works in the newly released figwheel 0.5.13

excellent

@tony.kay I believe this should address the Figwheel issues you saw, totally unrelated to :modules

https://clojurescript.org/news/2017-08-16-release

@bhauman Sweet. Thanks @dnolen.