Fork me on GitHub
#clojurescript
<
2019-10-02
>
iha202:10:20

I trying to get the values of a protocol definition from another namespace and there is no success. Can someone help me with this? (edited) How does one accomplish this? (edited) I am using clojurescript by the way.

thheller06:10:54

@iha2 define "get the values of the protocol definition"? there are only functions defined by the protocol you can call? no values to get?

iha217:10:19

(defrecord Nav [text link nav]) (def articles (map-indexed #(Nav. (->> % second :title) ’(::article {:id (->> % first)}) nil) (:articles @app-state)))

iha217:10:24

(js/console.log (:text (first nav-tree)))

iha217:10:39

I made a mistake when I said protocol

iha217:10:43

I meant record

iha217:10:41

When I import the value with the record, if I want to get the text property (as defined above), I get null.

iha217:10:56

however if I print the record I see it.

thheller17:10:23

it isn't clear what (js/console.log (:text (first nav-tree))) this is?

thheller17:10:39

(:text the-record) should be fine

thheller17:10:38

the map-indexed looks suspicious to me. it expects a (fn [idx val] ...)

thheller17:10:55

I don't think you can use second or first and instead should be using %1 and %2

iha217:10:27

the nav-tree is a list, that’s why I’m using first

iha217:10:52

I can just post both files to avoid confusion

thheller17:10:23

the entire (def articles ..) looks very strange to me. so I would check if that outputs what you expect first

thheller17:10:01

I doubt it does. seems very likely to me it just creates (Nav. nil nil nil)

iha217:10:21

I’ll look into it

Mikko Harju07:10:27

Our cljs-project has 702 CLJS files and some 16 dependencies as well. It seems that when a source file changes, and figwheel-main recompiles it, it is sending everything to the CLJS compiler to do its thing. The performance with lein-figwheel is better, almost 3 times faster, which means 10 seconds in comparison to 30 seconds of compilation after a file has been saved. How one should react to this? Should modularization help? The project we are doing will be getting bigger in size, and I started transitioning from lein-cljsbuild+lein-figwheel to figwheel main to modernize the build tools at the same time. My workflow has always been to evaluate stuff from the editor directly, and not relying on the figwheel’s reload functionality that much. However the rest of the team are used to just let figwheel compile the stuff, and see the changes in the browser.

thheller07:10:06

I don't have any advice regarding figwheel but others have told me that shadow-cljs is substantially faster in bigger projects

Mikko Harju09:10:07

Thanks for pointing this out. Actually I was going to give shadow-cljs a spin too at this point for some benchmarking. I really like it – thanks a lot for making it! I’ve used it in many smaller proof-of-concept and other short lived projects and it has worked very well.

plexus11:10:05

For what it's worth, at Nextjournal we disabled the auto reload from fogwheel, instead just using a repl workflow where you reevaluate the forms you change. Can't get much faster than that.

Mikko Harju12:10:15

@U07FP7QJ0 yes. That’s what I’ve been saying. Maybe that’s what I’ll start enforcing 😄 Thanks!

ingesol21:10:30

@U07FP7QJ0 So just so I understand the approach correctly. I would change a reagent component function, send the function to the repl. But I guess I would also need some mechanism to render the UI again to run the updated code?

ingesol21:10:29

maybe I’m missing the obvious. Maybe creating my own shortcut in the REPL for running my render-fn

Mikko Harju05:10:58

@U21QNFC5C, exactly. Just provide a shorthand for doing the re-mount after a change in a view function.

ingesol06:10:31

Tried it yesterday evening in Cursive, worked beautifully after a couple of tweaks. Really great!

👍 4
thheller07:10:58

there probably is an easy fix for figwheel though. it shouldn't take that long unless you are changing a file that literally every other file depends on somehow

Ben Hammond07:10:41

can I get a field value out of a deftype object? I have a value which is an instance of

(deftype Reconciler [controllers effect-handlers co-effects state queue scheduled? batched-updates chunked-updates meta watch-fns]
...
I was hoping I could use a keyword lookup, like (:state reconciler); but it keeps coming back as nil Is there some javascriptt accessor that I have to use?

roman01la07:10:46

it should be (.-state reconciler)

Ben Hammond07:10:59

oh square bracket work: reconciler["state"]

Ben Hammond08:10:30

js dot notation too reconciler.state

Ben Hammond08:10:57

agree that .- is more idiomatic

thheller08:10:22

@ben.hammond be careful with accessing internal things like that, it might not be safe in :advanced compilation

Ben Hammond08:10:27

I expect this particular thing to remain constant, it get sets once at :init time and then I'm only reading from it

Ben Hammond08:10:52

thanks for the warning though

Ben Hammond08:10:01

@thheller or do you mean that it might not be readable in :advanced?

Ben Hammond08:10:23

given a short name

thheller08:10:29

(.-state reconciler) should work

👍 4
thheller08:10:45

access via the string likely will not

Ben Hammond08:10:07

ah good to know, thanks

awb9909:10:07

Does someone have experience with cljsjs.ag-grid-react? I managed to get it going, but now I want to upgrade to cljsjs/ag-grid-enterprise. It seems that ag-grid-react is putting some wrapper on ag-grid-community, but this wrapper is missing in ag-grid-enterprise. There is also an cljsjs/ag-grid which uses ag-enterprise, but it is outdated as it uses the version 17 and not the current 21.

dominicm15:10:33

I use it at work

dominicm15:10:44

Cljsjs/ag-grid is deprecated

dominicm16:10:50

You can depends on enterprise, just make sure to require it after the community edition and it will upgrade the community edition

roman01la19:10:59

@thheller I wonder if you know the reason why shadow can be faster than figwheel main? Looking at figwheel through JVM profiler it looks like 99% of the time goes into cljs compiler

thheller19:10:51

@roman01la I suspect figwheel-main is just doing more work than it should. one common reason is the over eager :recompile-dependents where shadow-cljs uses a "different" strategy leading to less recompiled files overall

thheller19:10:35

:recompile-dependents is a CLJS compiler options so not figwheel specific. entirely possible that CLJS itself is doing too much and not figwheel