Fork me on GitHub
#clojurescript
<
2018-01-11
>
iperdomo14:01:50

it was largely inspired by some code found in Om source code, but for some reason i didn't manage to get a constructor function that have a div_ property so i workaround it by having a getDiv function

iperdomo14:01:13

the code works, but i was wondering if there is any improvement one can make do to it to feel more idiomatic

rauh14:01:36

@iperdomo You can just write the initialization inside your ctor function, no? Also, you can use extend-type instead of specify! here.

iperdomo14:01:00

@rauh i tried to do the initialization, but some how the div DOM element was not accessible afterwards by using (.-div this)

iperdomo14:01:38

@rauh don't we need protocols to implement or can I reference a JS constructor like js/google.maps.OverlayView ?

rauh14:01:03

@iperdomo Like this:

(let [c (fn [] (this-as this
                 (set! this -div "foo")))]
  (extend-type c Object (get-it [x] (.-div x)))
  (let [i (new c)]
    [(.-div i) (.get-it i)]))

iperdomo14:01:01

my attempt was ...

iperdomo14:01:44

i guess because (.-div this) doesn't exist i can't set it, right?

borkdude16:01:04

I used #_ to ‘comment’ some code out, but I got a compiler error. Could be reproduced like this: #_::foo/bar, should that break things if foo is not a valid ns?

borkdude16:01:56

In JVM Clojure this doesn’t throw

borkdude16:01:15

oh, it does…

bronsa16:01:19

yes it does

bronsa16:01:30

#_ ignores a form after that form has been read

bronsa16:01:38

if it’s not readable, it will error

borkdude16:01:00

This throws (from the REPL) (+ 1 2 #_::foo/bar 3), but this is accepted: #_::foo/bar

bronsa16:01:00

the only comment syntax that prevents reading is ;

bronsa16:01:36

@borkdude no, neither works

borkdude16:01:57

In my JVM repl: dre.standalone=> #_::foo/bar dre.standalone=>

bronsa16:01:42

that’s an artifact of whatever repl you’re using

bronsa16:01:53

this is not how clojure works

bronsa16:01:08

user=> #_::foo/bar
RuntimeException Invalid token: ::foo/bar  clojure.lang.Util.runtimeException (Util.java:221)

borkdude16:01:22

I’m using boot repl. Not sure why it behaves like this.

bronsa16:01:38

no idea, might have to di with nrepl

borkdude16:01:56

not important. thanks for the insight

bronsa16:01:11

I recommend using the new clj instead of lein repl or boot repl, it’s way faster and avoids having these issues

frenata16:01:18

#_ reads but does not evaluate, right? I think the main implication is that the form that #_ operates on has to be syntactically valid?

bronsa16:01:20

altho because it reads, it can technically evaluate via read-eval

justinlee16:01:08

is the goog/inherits mechanism equivalent to the es6 extends keyword? I’m asking because the rum code base seems to use the former when instantiating a component and I want to make sure I understand what’s going on

rauh17:01:17

@lee.justin.m Pretty much, yeah. extends will still be transpiled by google closure compiler unless you have language-out set to some "new JS". Though, the GCC transpiler uses a few smarter ways to extend the class

justinlee17:01:01

you are assuming I truly understand what extends does 😛

justinlee17:01:41

is ctor a common clojureism? I see in in several libraries and in the clojure source

justinlee17:01:35

i think in rum and sablono it must mean clojure-to-react

manutter5117:01:46

I've seen that used as shorthand for "constructor"

mikerod18:01:57

@lee.justin.m @manutter51 It is commonly used as “constructor”. That is true in the Java ecosystem too

mikerod18:01:07

If it means clojure-to-react in those libs, that would trip me up 😛

mikerod18:01:09

This isn’t definitive, but I took a glance at rums usage of the ctor name and it looks like it means “constructor” there to me.

justinlee18:01:15

forehead slap. thanks that should have been obvious.

iperdomo18:01:11

@rauh thanks for your previous comments, i have updated a working implementation based on extend-type instead of specify! https://gist.github.com/iperdomo/44911ee4ceaafa472338155edc992cbc

iperdomo18:01:52

works on my machine

rads21:01:41

has anyone run into caching issues with the CLJS compiler and NPM deps? in our project we can't use lein doo without lein clean first because for some reason the CLJS compiler does not include the NPM deps the second time

rads21:01:08

I'm not sure if this is an actual compiler problem or something to do with our own project. just wanted to see if anyone else had similar issues before I investigate further

rads21:01:19

the error looks like this (only shows up after a second run):

goog.require could not find: module$Users$rads$src$my_project$node_modules$honeybadger_js$honeybadger
we are using (:require [honeybadger-js :as hb]) in the CLJS code

rads21:01:11

if I copy the files into my project and use :foreign-libs instead the problem goes away