Fork me on GitHub
#clojurescript
<
2015-08-23
>
bhauman00:08:04

@val_waeselynck very well done! Only read half so far. But so far I t's terrific!!

paradoxquine06:08:27

@val_waeselynck: thank you!! this is awesome

val_waeselynck07:08:27

@bhauman thank you :) I guess it's a bit lengthy yes. At this point I think the most important is to find what questions are missing.

wamaral08:08:12

First time I edit a wiki page on github, hope I didn't mess up your FAQ @val_waeselynck

meow11:08:12

@val_waeselynck: excellent work on that FAQ

val_waeselynck11:08:38

@meow: thanks simple_smile watch out for more

paulspencerwilliams13:08:04

Hi all, is anyone happy discussing the merits of using Om vs microdata to push data to a HighCharts graph?

paulspencerwilliams13:08:35

In particular, how to port a current ‘production’ approach in another project into a more clojuresque approach for learning.

machty16:08:11

let's say you're writing code (client or server) that receives a stream of JSON objects, say, for people in a Contacts list. It's the job of your code to just store this in an in-memory hash map/set for easy retrieval. The JSON payloads are full representations of a Contact, such that even if just the name of a contact is changed (while email, phone, etc, remain the same), the incoming JSON payload includes ALL fields of a Contact including those that haven't changed.

machty16:08:58

you want to take advantage of data structure reuse such that you're not building entirely new ClojureScript objs from the parsed JSON and swapping out what's in the dictionary

machty16:08:13

I suppose you could first do a lookup of the ID of the contact that's changing, and then diff what's actually changed and then do selective assoc-in on the existing Contact to generate a new value for that Contact

machty16:08:31

but is there some generalized concept / approach for this sort of thing in Clojure/Script?

machty16:08:11

where freshly and separately created objects are merged to share immutable state?

machty16:08:47

or is it something you always have to implement yourself on a case-by-case basis

val_waeselynck17:08:27

@machty: if your local store is datascript, then it is trivial

val_waeselynck17:08:18

otherwise, assuming the store is a map which keys are Contact ids, and values are the contacts themselves, you can just do something like (update-in contacts-store [contact-id] merge contact-data)

machty17:08:54

darwin: yeah that's exactly what i was thinking of

machty17:08:11

i guess i wish the following were magically true: (identical? '(1) '(1))

machty17:08:26

i can understand why the overhead to making that work universally might be nuts

machty17:08:12

performance aside is there any reason why it'd be desirable to keep = and identical? semantically separate?

machty17:08:36

in a perfect world would you ever want = and identical? to return different results?

darwin17:08:49

@machty: = and indentical? are different, = is (potentially) deep equality check, indentical? is just a pointer check

machty17:08:56

totally agree

darwin17:08:19

you have to decide where do you want to pay for deep equality check

darwin17:08:04

if your code is being modified often and read once, you want to pay during read, or vice-versa

darwin17:08:18

my overwrite-map pays during write

machty17:08:24

but as far as the clojure philosophy of state/values goes, it seems that there's no philosophical reason for distinguishing between whether two equal objects (as per =) have different pointers

darwin17:08:01

indeed, that would be nice, but someone would have to do equality check (even if it was hidden in language runtime)

machty17:08:18

thanks for indulging, just trying to grok the philosophy

machty17:08:25

i guess it makes sense that (= (atom {}) (atom {})) => false

machty17:08:30

atoms are identity

machty17:08:53

= doing pointer comparison makes sense in that case

machty17:08:26

i'm guessing = is the same as identical? for atoms

darwin17:08:53

I don’t think so, let me test it real quick

machty17:08:59

(i did, it's false)

darwin17:08:32

maybe they return same results for atoms, but internally it does different operation, identical? is just a pointer check, = will do deep equality comparison of atom members, one of those members is probably some kind of reference-number to atom’s val, so they cannot be equal, even if deref-ing both returns equal values

darwin17:08:48

no, you are right

darwin17:08:58

looking at the source, it implements IEquiv

machty17:08:20

(where are you looking this stuff up?)

machty17:08:39

the only feature an atom has (afaik) is what it points to

darwin17:08:53

@machty: so this could be changed, atom could do equiv test on deref’d values

machty17:08:07

i don't think that'd make sense though

machty17:08:19

atoms are used for identity

machty17:08:28

shared identity

machty17:08:11

they may point to the same value but they are not equal

darwin17:08:48

ok, I also think current implementation makes more sense

darwin17:08:22

wanted just point out that you can have your own atom, with different semantics

mtraven17:08:56

Planck looks great but the examples involving require aren't working for me. Any advice?

$ planck
cljs.user=> (require '[planck.core :refer [slurp]])
cljs.user=> (slurp "/tmp/foo")
WARNING: Use of undeclared Var cljs.user/slurp at line 1 
undefined is not an object (evaluating 'cljs.user.slurp.call')

xificurC19:08:08

what is the difference between js/getElementById and goog.dom/getElement?

val_waeselynck19:08:48

accepts both element id strings or elements

xificurC19:08:02

@val_waeselynck: thanks, so it doesn't really matter which one I use if I'm passing in strings

val_waeselynck19:08:20

yeah, I'd personally go with js/getElementById in this case, more transparent IMO.

bhauman22:08:12

@val_waeselynck: I don't think the statement that JavaScript was developed in weeks is going to be taken seriously by serious JS devs

bhauman22:08:18

Maybe just say that JavaScript is impressive considering that it was initially developed in a much shorter design cycle and the idea that it was going to be the most prevalent programming language was far from the authors mind. Or something a little more political like that

mfikes23:08:35

@mtraven: that looks odd. What version of Planck do you have? (`planck -h` shows the version number.)