Fork me on GitHub
#clojurescript
<
2017-07-27
>
alexhrescale02:07:33

In clojure, it’s easy to take a paginated REST endpoint and turn it into a lazy-seq and call take against it, but you can’t do that in clojurescript. Is there a nice strategy for dealing with async paginated endpoints?

val_waeselynck05:07:53

core.async is probably the tool for that

alexhrescale08:07:51

thanks. looks like lazy-seq on an async response isn’t going to happen. Just going to stick with reactive logic

val_waeselynck09:07:21

indeed, lazy seqs are essentially synchronous, so not compatible with event-driven I/O

kaosko04:07:59

probably lots of you using reagent yes? how the heck do you deal with touch events in a case where the element starting the touch event isn't the one that's supposed to track touchmove events? (like drag this element, but the container tracks the position)

cjhowe05:07:46

btw there's #reagent

kaosko05:07:40

oh I better go there

rauh07:07:04

A little PSA: If you use Polyfills (which you'll need to if you want to use React 16 which needs Map/Set polyfills) you'll need to load any 3rd party code (such as React) AFTER your CLJS compiled code. Or otherwise the React code will load without seeing the polyfills. This will result in an error in older IE's which rely on the polyfills. Reason: React will not see the Symbol.iterator and map it to undefined and fallback to @@iterator. However the polyfill from google closure compiler will later define it and CLJS will define all iterables with a different Symbol which then mismatchs and will error.

pesterhazy08:07:21

@rauh, so just load the polyfill as a separate script tag at the very top of your head?

rauh08:07:27

@pesterhazy Is there a way to output the polyfills that GCC generates into a separate file?

pesterhazy08:07:45

I don't know - I know GCC only as a dumb user

pesterhazy08:07:15

but shouldn't all polyfills be equivalent?

pesterhazy08:07:25

frankly that already sounds completely wrong as I'm saying it

rauh08:07:42

@pesterhazy GCC will look at your code and add polyfills at the beginning of your output only for the constructs that you actually use (so for instance now with React I added a dummy (def ^:export polyfill-gen #js[(js/Map.) (js/Set.)])

thheller08:07:16

@rauh you can force GCC to inject things, not sure there is an option for it in cljs yet

thheller08:07:13

CompilerOptions.setForceLibraryInjection takes a list of names, ie. es6/set

rauh08:07:30

Oh I see what you mean. For this, there is no option AFAIK

thheller08:07:30

no not that one 🙂

pesterhazy10:07:32

Just spend a few hours trying to debug a problem with npm/yarn. Two different versions of yarn resulted in different yarn.lock files with vastly different behavior. One ended up including multiple versions of React in the bundle which I didn't know was possible.

dnolen11:07:54

@pesterhazy that’s interesting, at the top level? that said I’m not sure we can really do anything about stuff like that

pesterhazy11:07:04

@dnolen I should have mentioned, this was using webpack, not using npm-deps yet

pesterhazy11:07:35

so nothing for clojurescript to do. I don't think both versions were at the top level, actually I think that's impossible

pesterhazy11:07:12

but one dependency pulled in its own version, resulting in the dreaded Uncaught Error: addComponentAsRefTo(...): Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component’s render method, or you have multiple copies of React loaded error

pesterhazy11:07:45

npm's dependency resolution scheme is way too complicated, if even different versions of yarn cannot agree on how to resolve conflicts

lsenta12:07:27

Hi there, I've been writing some javascript as a goog.closure module for my project

lsenta12:07:37

I wrote it in ES6 to get nice looking maps, arrow functions, etc

lsenta12:07:11

it works in figwheel but the google closure compiler won't build

Jul 27, 2017 2:44:20 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/laurent/dev/singulargarden/awkward-majine/src/cljs/awkward_majine/buffers.js:7: ERROR - this language feature is only supported in es6 mode: arrow function. Use --language_in=ECMASCRIPT6 or ECMASCRIPT6_STRICT to enable ES6 features.
  const numberOfChannels = buffers.map(x => x.numberOfChannels)

...

ERROR: ES6_FEATURE. this language feature is only supported in es6 mode: const declaration. Use --language_in=ECMASCRIPT6 or ECMASCRIPT6_STRICT to enable ES6 features. at /Users/laurent/dev/singulargarden/awkward-majine/src/cljs/awkward_majine/buffers.js line 42 : 4

lsenta12:07:28

is there a way to pass the language option down to the closure compiler?

rauh13:07:31

@lsenta Yes, it should be documented on the cljs website (I'm too lazy to find the link)

rarous13:07:17

@lsenta add :language-in :ecmascript6 to your compiler options map

lsenta13:07:11

Thanks @rauh @rarous my code is going through the compilation now!

lwhorton15:07:49

i know clojurescript doesn’t support resolve or intern, but is there a way to use the js environment to achieve the same effect?

lwhorton15:07:10

for example, using a :preloads while building for dev where my preload file might redefine a function implementation?

spinningtopsofdoom15:07:22

See the CLJS Loader section

jeaye18:07:24

Looks like a bug to me, but could something I'm missing.

jeaye18:07:15

You're right, it appears to be in figwheel. I can go bug them. 🙂

darwin18:07:42

same bug in planck 2.5.0, works as expected in lumo 1.6.0

darwin18:07:43

I guess, this will be somehow related to namespaced keywords

jeaye18:07:04

Yeah, appears to be so.

mfikes19:07:10

@jeaye ^ this occurs in a plain-vanilla shipping Node ClojureScript REPL, but not with ClojureScript master

anmonteiro19:07:19

probably because of the tools reader upgrade / cljs.reader revamp

anmonteiro19:07:38

that fixed a lot of lingering stuff, such as reading namespaced maps with cljs.reader as well

jeaye19:07:45

This is the latest figwheel snapshot, so looks like something will be needing a fix.

noisesmith19:07:03

survey has no entry for “I never used parinfer but coworker who used it kept breaking namespaces by letting it restructure other people’s badly indented code wrong”

rgdelato20:07:16

Just curious, do you know what editor they were using?

noisesmith20:07:22

it could have been a user error of course, it just repeatedly happend even after we discussed the issue

rgdelato20:07:35

Thanks, that's good to know. (To contrast, in Atom, when you open a file that would have it's AST changed by Parinfer, you get a prompt to kind of minimally re-indent the file so that that doesn't happen. Maybe something to look into for the Cursive implementation.)

noisesmith21:07:56

cool @U0567Q30W - you might be interested in this?

cfleming21:07:13

In theory Cursive does do that, in practice it’s flakey and I haven’t managed to figure out why.

cfleming21:07:31

There’s a race condition in there somewhere - IntelliJ is complicated.

cfleming21:07:24

(not that I’m defending the bug, but I’d hope everyone revises their changes before checking something in, too…)

noisesmith21:07:11

yeah, that plus making sure the code in master has processed by cljfmt was a workable solution

noisesmith21:07:11

if I had implemented git I would make the -p arg to git add the default, and require an explicit arg to turn that behavior off

jeremys21:07:21

Hey guys, I have been playing with :npm-deps in “1.9.820”. And i have some questions 🙂 I added {:material-components-web "0.15.0"}. This pulls a lot of @material.components in the node_modules. What is the right way to require these components ? I tried

(ns foo (:require ["@material.component.foundation" :as c]))
and
(ns foo (:require ["@material/component.foundation" :as c]))
but it doesn’t work... How can I properly require this ?

jeremys21:07:57

Also is there a way to tell the compiler not to install npm dependencies every time it recompiles on file change ?

anmonteiro22:07:20

@jeremys I can help you require those namespaces but I need to know what the directory structure looks like

anmonteiro22:07:53

what is the directory called, and what is inside it

jeremys22:07:00

@anmonteiro you have for instance “node_modules/@material/textfield/foundation.js”

anmonteiro22:07:30

so that would be (:require ["@material/textfield/foundation"])

jeremys22:07:11

Ok the error isn’t the same now!

jeremys22:07:39

java.lang.AssertionError: Assert failed: cljs.analyzer/foreign-dep? expected symbol got "@material/textfield/foundation"

sh3rawi22:07:11

im trying to use an npm dependency, as per https://anmonteiro.com/2017/03/requiring-node-js-modules-from-clojurescript-namespaces/, i see cljsbuild print “Installing Node.js dependencies” but there’s no node_modules folder, and it stops the build becuase “No such namespace: left-pad, could not locate left_pad.cljs, left_pad.cljc, or Closure namespace “left-pad” in file src/engine/core.cljs”

anmonteiro22:07:34

@jeremys did you build CLJS from master?

anmonteiro22:07:54

@sh3rawi make sure you have a package.json in your project’s directory

anmonteiro22:07:04

even if only with {} as the contents

jeremys22:07:28

yep I am on “1.9.820”

sh3rawi22:07:34

@anmonteiro thanks, but shouldn’t this be documented somewhere?

sh3rawi22:07:47

i was under the impression that this negates the need for this

anmonteiro22:07:53

it’s an NPM idiosyncrasy

anmonteiro22:07:01

we still shell out to NPM

jeremys22:07:26

@anmonteiro Yep I build it from master v1.9.820

anmonteiro22:07:20

that’s weird because we have tests for that

jeremys22:07:55

I am rebuilding. As an aside, can tell the compiler not to install npm deps when recompilling on every file change ?

anmonteiro22:07:38

@jeremys I think you wanna build from current master

anmonteiro22:07:41

and install the dependencies yourself

anmonteiro22:07:01

current master is probably 1.9.837 or something

jeremys22:07:17

yeah I just pulled and re-buimt and that the version I have now

anmonteiro22:07:22

you now need to opt-in for dependency installation (with a flag :install-deps)

anmonteiro22:07:47

but you can just pass :npm-deps and :install-deps false (which is the default)

anmonteiro22:07:10

^ this means: “I will install my own dependencies, but be aware of them”

jeremys22:07:05

ok cool because it slows down the compillation and makes figwheels hot reaload a bit slow...

anmonteiro22:07:58

I think you don’t even need to provide :npm-deps

anmonteiro22:07:12

the compiler will index a top-level node_modules installation if it finds one

jeremys22:07:35

ok good to know

anmonteiro22:07:05

@jeremys @sh3rawi thanks for giving these a go

anmonteiro22:07:23

we definitely want to make sure everything works as expected before releasing the next version

anmonteiro22:07:41

tests help, but people breaking stuff is a better method to ensuring that 🙂

jeremys22:07:39

Although it is nice to be able to declare npm deps from your project.clj without worrying about npm

jeremys22:07:52

Is it possible that lein cljsbuild doesn’t use my version of the compiler ? i still have the assert not passing...

sh3rawi22:07:50

@anmonteiro you’re welcome! good luck with the release

sh3rawi22:07:58

im now experiencing another problem

sh3rawi22:07:07

Compiling “js-release/cljs_engine_bare.js” failed. java.lang.RuntimeException: INTERNAL COMPILER ERROR. Please report this problem. null Node(NAME Events): /Users/sh3rawi/workspace/jawaker/clj_engine/node_modules/backbone-events-standalone/backbone-events-standalone.js:85:23 var _ = miniscore(), Events; Parent(VAR): /Users/sh3rawi/workspace/jawaker/clj_engine/node_modules/backbone-events-standalone/backbone-events-standalone.js:85:2 var _ = miniscore(), Events;

anmonteiro22:07:18

@jeremys make a minimal repro that I can take a look

anmonteiro22:07:24

will have to wait until a version of Closure is released with this fix ^

sh3rawi22:07:11

cool, ill have to seek another library. Thanks for the quick responses 🙂

jeremys23:07:56

@anmonteiro ok sorry for the delay it’s getting late on my side of the atlantic... https://github.com/JeremS/class-test-npm

anmonteiro23:07:45

thanks I’ll have a look later