Fork me on GitHub
#clojurescript
<
2017-02-22
>
qqq00:02:06

I seem to have the following problem: if my code calls itself, and it does an (assert false), I get a stack trace fine in dirac/cljs-devtools However, if my code creates a (fn [] ... ) which reagent/react calls later -- and that function does an (assert false) -- then, instead of getting a tack trace, it loks like react catches it, returns NIL, and throws some other error

qqq00:02:29

If the above is true, is there anyway to tell react to not catch exceptions, and let the exceptions remain uncaught so I can get my stack frames?

qqq00:02:10

@darwin: slack says you have been typing for a long time with no response, 🙂

darwin00:02:59

My brain had stack overflow...

darwin00:02:13

You should be able to “Pause On Caught Exceptions” in Chrome DevTools. This should allow you to identify who is exactly catching those exceptions thrown by your assert. Then you should be able to address it based on that information.

darwin00:02:38

this is not really clojurescript related question I believe, this is general javascript problem

qqq00:02:14

@darwin: lol, (1) I posted in #cljs isntead of #dirac thinking it'd be off-topic in #dirac (2) unfortunately, this hits an caught exception in (devtools.core/install!)

darwin00:02:30

hit F8 to continue until you stop on the assert-caused exception

darwin00:02:05

I understand that it could be annoying to stop on other exceptions, that is a reason why I think it is a bad practice to use exceptions to do normal non-exceptional control flow

darwin00:02:16

why is (devtools.core/install!) throwing?

qqq00:02:46

should we move this to dirac? where it's atleast closer than #clojurescript ?

darwin00:02:26

I’m going to bed

qqq01:02:40

is there any library that changes chrome dev tools into a SERVER which I can then connect to via emacs? I'm not looking for brepl; I want chrome canary to open up a port that emacs can talk to

iku00088801:02:40

@qqq Don't know much my self, but figwheel won't do?

jdeisenberg02:02:59

JS interop question [minimal case]: given this nested map (def m {:location {:city "San Jose"}}) I want to convert the city to uppercase, but (update-in m [:location :city] .toUpperCase) does not work; where am I going wrong?

iku00088802:02:26

try (update-in m [:location :city] #(.toUpperCase %))

mfikes02:02:35

A couple of interesting alternatives:

(update-in m [:location :city] (memfn toUpperCase))
or the portable:
(update-in m [:location :city] clojure.string/upper-case)

mfikes02:02:04

Actually, I suppose all 3 are portable 🙂

bbss02:02:15

@negaduck you asked yesterday about a weird compilation error and I asked about the version, thinking I saw something that might be related yesterday for the latest version. But it may also actually hit your version: http://dev.clojure.org/jira/browse/CLJS-1948

anmonteiro05:02:20

it's only the beginning of what it could become

anmonteiro05:02:46

long way to go still, until we achieve feature parity with what the JVM compiler gives us

minikomi05:02:05

yeah I understand there's a lot of caveats / work to do

anmonteiro05:02:10

(also possibly some improvements to the Closure Compiler JS needed)

minikomi05:02:41

still, I'm bullish on cljs so anything which expands its reach is happy news for me 😄

xsyn06:02:33

@anmonteiro this is incredible, thank you for the efforts

negaduck11:02:54

@bbss, I’ll probably look into that later, thanks. That strange problem is solved by serving files separately from figwheel: https://github.com/emezeske/lein-cljsbuild/issues/458#issuecomment-281647384

tech_hutch14:02:36

(Rewrote this message to be more concise.) I want to include foreign libraries, so I'm trying the example at https://clojurescript.org/reference/dependencies#bundling-foreign-javascript-code. (However, I am running this on node, without advanced compilation; the examples on that page are for the browser.) I have a "yayquery.js" file that's the same as theirs. My build script: https://hastebin.com/ikevizihap.clj (I omit externs since I'm not using advanced compilation) My core file: https://hastebin.com/melosegoqi.clj When I try to build, I get errors: https://hastebin.com/pokabumugi.txt How do I include foreign libraries when using node?

tech_hutch14:02:17

I tried adding externs, but it didn't change anything.

tech_hutch14:02:00

(Should I be in the #beginners channel?)

jdeisenberg16:02:37

ANN: Transforming Data with ClojureScript (online book in progress) The book, at http://langintro.com/cljsbook has interactive examples and is written for people who have not programmed before or are beginning programmers. The book is about two-thirds complete. Comments welcomed.

mikebelanger17:02:43

@tech_hutch Have you tried passing the yayquery.js argument as a relative path? Looks like it wants relative paths (line 42 of the stack-trace)

tech_hutch17:02:13

I have not. I was trying to figure out where it was relative to. What's strange is that both putting the file in selfbot-cljs and in selfbot-cljs/src caused the error to show the right path to the file (selfbot-cljs or selfbot-cljs/src). I believe that the documentation says that it's relative to classpath, but what is that, since, as per the guide, I'm passing both cljs.jar and src with the -cp flag on the command line?

mikebelanger18:02:45

@tech_hutch hmm, have you tried renaming selfbot-cljs to selfbot_cljs. There's that weird thing about Java not liking hyphens in the classpath.

mikebelanger18:02:54

....and for some reason, underscores have to be used as a substitute for hyphens. Weird, I know.

tech_hutch18:02:03

Oh, I didn't know that.

tech_hutch18:02:55

I did remember reading something about namespace hyphens needing to be underscores in the file path, but I didn't know this applied to the whole path.

mikebelanger18:02:54

@tech_hutch I'm not sure if that will solve your problem, just a guess.

mikebelanger18:02:42

@tech_hutch I figured it wanting 'relative paths' translated to class paths 😛, and therefore no hyphens. But those two ideas might be completely separate concerns

tech_hutch19:02:58

Now I'm having another problem where I can't get a repl running from the browser. It was working yesterday. I'm not sure what's different.

tmayse19:02:44

I'm getting "Figwheel Server: Resource not found Keep on figwheelin'" in the browser even though it looks like figwheel started fine on the commandline - it was working yesterday, but now I can't figure out where things are going south

mobileink19:02:33

hi list. i'm working on a clojure (not clojurescript) thingie for webcomponents https://www.webcomponents.org. i have only a thin understanding of react, om, etc., but it looks like they all do sth more or less similar to what webcomponents do, in different ways. what's the clojurescript take on webcomponents?

dnolen19:02:23

there isn’t really a take on webcomponents

dnolen19:02:55

I’m sure some higher level thing could be done with them to make them more functional friendly

tech_hutch20:02:29

I'm not sure what I'm doing differently now, but the repl in the browser is working now. Now to troubleshoot my other issue…

mobileink20:02:46

yep, that's basically my project. now that it's close to done in clojure i'm looking at cljs. om etc. and web components are not the same thing, but it looks like there is considerable overlap.

mikebelanger20:02:19

@mobileink in what way is om/React like WebComponents? In terms of their shadow dom stuff?

emccue20:02:04

Does anyone have advice for getting cursive running on a pycharm installation?

dnolen20:02:16

@emccue pretty sure not possible, you need IntelliJ not one of the standalone dev things - you might want to double check that in #cursive

emccue20:02:57

Nah that's fine, I just need to get the student license for that and I should be fine

mobileink20:02:28

@mikebelanger that, and what polymer https://www.polymer-project.org/1.0/ calls "data binding". as it happens, i have a defcomponent macro that from about 10,000 feet looks like defui from Om Next. But my defcomponent gets "compiled" to produce html + javascript, so it ends up using shadow dom. does Om Next use shadow dom?

dnolen20:02:57

@mobileink Om Next is just a wrapper over React, doesn’t use Shadow DOM

mobileink20:02:29

ok, thanks. one of the advantages, they say, of shadow dom is no css leakage. styling of custom components is not affected by app-level stylesheets. is that an issue in practice for Om/React?

sova-soars-the-sora20:02:29

I have a strange question: lein run complies clj, cljs, and opens a browser for my builds.

sova-soars-the-sora20:02:11

However, not always does a server start on localhost:517621 or whatever random port number, and it's a bit perplexing. Usually I can get a server running within an attempt or two, but sometimes I just don't get a server running & it's not very straightforward to debug.

mobileink20:02:45

fwiw i'm looking to steal the best bits of everything. simple_smile

mikebelanger20:02:16

@mobileink cool - yeah WebComponents, shadow-dom look promising. I'd be interested to see your library.

mobileink20:02:03

couple more days. as I have been saying to myself for a couple days. 😉

mobileink20:02:46

more generally, i'm filosofizin' about the effects of webcomponents on stuff like react, om, etc. if all the major browser vendors implement, as they have apparently agreed to do, then such things will become at least partially obsolete. at least some of the problems they were designed to solve will have been solved in a standardized way.

mikebelanger20:02:43

@mobileink I was about to say, the only issue with WebComponents is browser coverage. Sadly, lots of good ideas like WebComponents either didn't get covered widely enough, or get poorly implemented (ie RSS, animated PNG).

mikebelanger20:02:55

@mobileink Sorry for sounding pessimistic. And at this point I guess I'm off-topic 😛

mikebelanger20:02:59

@mobileink What I'm trying to say is that while WebComponents look promising, its very possible for browsers to retract their commitment to them, and React and their wrappers will become the de-facto standard for quite a while.

mobileink20:02:07

my official policy is to worry about that stuff later. it'll all be good by 2020!

dnolen20:02:13

@mobileink for many applications CSS leakage isn’t a real problem

dnolen20:02:41

WebComponents is trying to solve the reusable styled component issue

dnolen20:02:47

but that might be irrelevant for your SPA

mobileink20:02:16

besides, some really great clojure/clojurescript libs will surely make all the difference.

mobileink21:02:51

@dnolen i kinda suspected that. but the other nice thing about wc is you can just drop it in to any webpage, in principle.

mobileink21:02:35

even stuff not written in clojure.

mobileink21:02:50

in principle i do not see why you could not do that with compiled Om components. i wonder if anybody actually does that?

mobileink21:02:13

@mikebelanger yes, there is a risk. but in this case i think it's relatively low. when i started on this a year or 2 ago, polymer was the only game in town. but now look at https://www.webcomponents.org. an embarrassment of riches. it's not just google; check out https://www.polymer-project.org/1.0/blog/2016-03-10-community-highlights-predix-ui. with that kind of big $$$ backing it seems a safe bet.

mikebelanger21:02:33

@mobileink cool, yeah if GE is backing it too, makes it all the more promising

mobileink21:02:27

of course they have enough money to get it completely wrong and not break a sweat, but still. i believe even the behemoth from Seattle is on board, but you never know with them.

mobileink21:02:20

that's pretty good coverage, imho.

thheller21:02:31

@mobileink web components sound cool but it is basically just a thin layer on top of the usual stuff

thheller21:02:49

you still work with mutable things

thheller21:02:08

React is a fundamentally different take on the whole thing

mobileink21:02:31

@theller except it's not a layer. it's in the browser.

thheller21:02:01

I mean a layer on top of the usual dom, so you can write custom elements

thheller21:02:33

so you can write <my-component>hello world</my-component>

thheller21:02:47

and it outputs a bunch more nested html wrapping the hello world

mobileink21:02:57

still not a layer.

thheller21:02:03

ie. a shadow-dom

thheller21:02:20

don't get hung up on the word layer, I don't know how else to describe it

mobileink21:02:20

ok my point is it is not just an add-on any more. it's built-to web stds.

thheller21:02:47

that is irrelevant to my point

thheller21:02:06

(also browser support is terrible, so you still need a bunch of polyfills)

mobileink21:02:41

react etc are hacks. very useful, but still hacks, only needed because the base atuff is lacking.

thheller21:02:04

they are not hacks, they are a completely different way of looking at things

thheller22:02:04

web components is basically doing it the old way just providing some sugar so it is easier to isolate things

mobileink22:02:45

ok. but what i mean is just that you would not need them if browser standards already did.

thheller22:02:55

and you can use web components with react, no problems

thheller22:02:10

well, some problems but still

mobileink22:02:36

it's not sugar if the browsers vendors build it in.

thheller22:02:56

maybe I am not making myself clear enough

thheller22:02:57

it is irrelevant that it is built-in (which it isn't btw: http://caniuse.com/#feat=shadowdomv1, http://caniuse.com/#feat=custom-elementsv1 support is terrible)

thheller22:02:28

what I mean by sugar: you write <my-component>foo</my-component> in your html

thheller22:02:56

you get <div><h1>foo</h1><div>some other stuff</div></div> as the result

thheller22:02:27

so you type less html and get more "re-use" in theory

thheller22:02:56

the issue is when things change over time, doing it with data-bindings and callbacks is annoying

thheller22:02:42

so we take React and (in theory) get a functional way of building UI

mobileink22:02:55

i confess i don't follow your last 2 comments, but give me some time. re: sugar, it's all sugar where naming is involved. defn is a sugar macro: it allows you to use a name instead of #(...). webcomponents are no different, really.

thheller22:02:26

oh wait I just saw you where talking in the context of clojure

thheller22:02:36

so server side generation of html

thheller22:02:46

React solves a completely different problem

mobileink22:02:48

e.g. you write (my-fn "foo") and you get the expansion of my-fn with "foo" plugged in.

mobileink22:02:06

hope i'm not sounding obstreperous, i find this all very fascinating.

thheller22:02:04

me too and I have been doing web development with javascript since MSIE 4

thheller22:02:43

the glory days of document.all .. oh the messes that created 😛

thheller22:02:38

I hate some things about React but the development workflow it enables is hard to beat

mobileink22:02:02

you poor sob! 😂

mobileink22:02:35

fwiw, having gotten my clojure thingie close to working, i'm looking at the clojurescript side of things and not having an easy time of it.

mobileink22:02:35

i just want one blasted language for everything. is that too much to ask???

thheller22:02:23

I am on pure clojure/clojurescript for coming up on 4 years now

thheller22:02:31

that is basically just one language 😉

mobileink22:02:16

aha, never write html/css? i guess we've wandered from clojurescript, heh.

qqq22:02:49

hiccup/garden

thheller22:02:36

writing normal html feels completely alien to me now

verma23:02:02

@thheller shadow.markup looks nice! 🙂