Fork me on GitHub
#clojurescript
<
2017-11-29
>
qqq02:11:06

I'm looking for something with direct dom access, i.e. not reagent/om/react

qqq03:11:16

I don't want the full power of react/reagent; I just want to, on client side, take a piece of hiccup, and render it into a HTML DOM Node. I can't do hiccup -> html -> document.write because this hiccu7 contains :onClick handlers and attached cljs functions

gklijs04:11:04

@qqq I was pretty disappointed with dommy and hipo, but used them as inspiration to write some util functions using the Google closure library. For example I have a function that takes hiccup syntax and create a node. Depending on the other parameters it's put somewhere in the Dom. For example you can replace an existing Id, of append to one.

gklijs04:11:29

@qqq there are even some closure utils in clojurescript core itself, but even those are out of date. If more people are looking for something like that, e.g. easy Dom manipulating, and adding some basic listeners. I might open source that part.

qqq05:11:26

@gklijs: I have this weird use case, where I have this entity-[attribute, value] store, where each entity has a corresponding SVG node / subtree. Then, whenever, I update an attribute of some entity, I need to modify the corresponding SVG node. I thought this would be fast in reagent, but it's slower than I thought, so I'm now trying to see if I can direcly mdify the DOM somehow.

qqq05:11:48

but it appears that Reagent/OM has pretty much killed everything else

gklijs07:11:34

Yes, it's basically the only way clojurescript is used it seems. I like working with websockets. And while I could update the state and wait for Reagent to render the page, it seems to make a lot more sense to directly change the Dom

qqq07:11:16

https://github.com/ibdknox/crate <-- yet another library I want to use for direct manip, also gone

gklijs07:11:42

@shaun-mahood enfocus uses domina for dom manipulation, which seems abandoned. Also it uses a different way to template.

gklijs08:11:56

There is also https://github.com/Respo/respo which might turn out to be really nice

qqq08:11:46

this looks interesting

qqq08:11:04

however, what is the benefit of having a virtual dom layer of indirection between cljs and the actual-dom ?

gklijs08:11:49

performance

qqq08:11:59

is the performance gains solely from all the updates being batched into the requestAnimationFrame ?

gklijs08:11:06

I guess that helps, I’m far from an expert on javascript, but I do know a large part of the success of react is the virtual dom. It’s probably (but now I’m really speculating) also a good way to fix differences in browsers, since you have a kind of ‘middleware’ to solve those.

qqq08:11:25

I'm looking at the respo virtual dom api.

qqq08:11:42

is there a way to say "take object with id ID, set attrigbute ATTRIBUTE to value VALUE"

qqq08:11:55

from what I have seen so far, we have to pass it another map, and it does diffing

qqq08:11:13

@jiyinyiyong: are you the author of Respo? (lots of the github wikipages I'm reading are last edited by you); can you comment on whether respo allows me to say "change object ID 's attribute ATTR to value V" directly on teh virtual dom ?

Jon03:11:50

not sure what you referring to

Jon03:11:58

yes, I made Respo

Jon03:11:32

there's no "object ID" in Respo.

Jon03:11:09

in theory, Respo uses virtual DOM, it's a tree data structure, which is also immutable.

Jon03:11:45

you can change the tree with any means available in Clojure. but I think it's unlike attribute manipulation in JavaScript.

Jon03:11:40

in Virtual DOM, you pass in a new map of props, its real props are changed by diff/patching inside a framework.

leonoel09:11:27

@qqq what prevents you from mutating your svg nodes with basic js interop ?

qqq09:11:00

@leonoel: nothing, but 1. if I use reagent/om, I have to worry about refreshing 2. if I don't use reagent/om, I need to do my own event handling + efficient way to create lots of nodes (requestAnimationFrame?)

leonoel09:11:21

I don't see how a virtual dom would increase performance with svg

qqq09:11:08

oh, because there is no reflowing with svg ?

leonoel09:11:57

reactive event handling is a problem of its own and it's kind of sad that all tools we have in clojurescript couple it with dom handling

qqq10:11:18

@leonoel: "reactive event handling is a problem of its own" <-- what does this mean ? // I thought the point was to have react abstract away all the browser incompabilities // what problems does it introduce ?

leonoel10:11:53

by reactive event handling I mean having a declarative way to compose event streams. this problem is totally unrelated to browser incompabilities and both should be solved separately imo

leonoel10:11:52

decomplected is the right word I guess

qqq10:11:16

isn't that the problem reactive-atom, which can be pulled out of reagent, solves ?

qqq10:11:23

you're referring to FRP right ?

leonoel10:11:38

FRP in the broad sense, yes

leonoel10:11:18

what is reactive-atom ?

leonoel10:11:54

ah ok I thought it had been pulled out of the main library

leonoel10:11:38

yes I think primitives like ratoms have value even without the dom stuff

qqq10:11:21

(defn foobar []
  (let [builder   (Builder.)
        sanitizer (.build builder)
        ss        (.sanitize sanitizer "<div>Hi<svg width=100 height=200><rect></rect></svg></div>")
        _         (. js/console log "ss: " ss) 
        x         (gdom/safeHtmlToNode ss)
        app-dom   (gdom/getElement "app")]
    (. js/console log "app-dom: " app-dom) 
    (.appendChild app-dom x)
    (. js/console log (str "x: " x))))
it appears goog sanitizer is killing my svg

gklijs11:11:12

@leonoel A colleague of mine helped open sourcing this https://github.com/politie/sherlock to help with reactive environments, not sure how usefull it is with clojurescript, as I would guess all the problems it solves are solved by re-frame as well.

leonoel11:11:57

thanks for sharing, it looks very similar to ratoms indeed

cmal12:11:20

Hi, I am currently working on a reagent program, the js file compiled using advanced mode get an error but the error is not found in the none mode compiled js file.

cmal12:11:45

Uncaught TypeError: k is not a function

function ka(a) {
return "function" == k(a)
}
What could this problem be?

fbielejec12:11:23

@cmal :advanced compilation mangles names to make the bundle smaller.

fbielejec12:11:25

most likely it's an interop problem, you're using a js library or calling js interop. For the former you need to provide externs file to let the compiler know which names not too touch.

thheller12:11:18

@cmal run shadow-cljs check <your-build-id>. it should complain about undefined properties.

p-himik15:11:44

I see that this https://dev.clojure.org/jira/browse/CLJS-308 was implemented, but I can't get the type hints to work. I have (defprotocol Ctx ...), and (defn x [^Ctx ctx] ...) below it. But it results in Unable to resolve classname: Ctx

p-himik15:11:03

Did I do something wrong?

thheller15:11:28

where do you get that error? (it is not a clojurescript error)

p-himik15:11:17

Hmm, the file is cljc, the error starts with Couldn't load Clojure file

p-himik15:11:30

While using figwheel.

thheller15:11:19

yeah I don’t think clojure allows type hints for protocols

p-himik15:11:23

I see. Thanks!

qqq17:11:13

is there any virtual dom that makes a "transactional behaviour "gurantee -- that either all the dom updates happen, or none of the dom updates happen -- but it'll complete 'only halfway'

thheller17:11:52

since the DOM is not transactional that is unlikely

qqq17:11:16

right, which is why I'm asking if there is a virtual-dom layer which does this

qqq17:11:30

i.e. it checks beforehand to see of all the changes can succeed, and, if not, rejects it

thheller17:11:04

why would anything fail though?

thheller17:11:01

the construction of the virtual dom elements is usually what fails, once that succeeds and the diff succeeds there should be very little else that fails.

qqq17:11:38

I don't know; I am trying to write my own diffing layer, realized things would be in an inconsistent state if only half the updates went through, then started wondering if virtual-dom could provide a solution

eoliphant18:11:19

Hi I have a quick question. I have a multimethod that works fine in clojure,but blows up in clojurescript

(defmulti get-default-def identity)


(defmethod get-default-def :text
  [val]
  {:field/id 1
   :field/name :newfield
   :field/label "New Field"
   :field/type :text
   }
  )

(defmethod get-default-def :longtext
  [val]
  {:something :else})
...
Running say (get-default-def :text) in clojurescript is causing an exception : #object[Error Error: Invalid arity: 0] Any idea what might be causing this?

jcr18:11:44

@eoliphant can't reproduce, works just fine. Try to restart your repl - maybe you've redefined your multimethod and stuff got mixed up somehow

eoliphant18:11:35

yeah it’s really weird, I have multimethods working fine elsewhere, restarting everything to see what happens

eoliphant18:11:03

it blew up in my code in the webpage first, and still did after I tried it in the figwheel repl

noisesmith18:11:56

@eoliphant FYI defmulti is like defonce, if the multi already exists it’s a no-op, so you need to delete the multimethod to make a new definition

eoliphant18:11:33

yeah that was the issue… ugh.. lol

noisesmith18:11:37

this is done intentionally because if re-evaluating defmulti created a new multimethod, it would break all the defmethod calls in the rest of your codebase

eoliphant18:11:53

basically I think there was an issue with it originally

eoliphant18:11:58

so the error was accurate

eoliphant18:11:13

but because of the need to do the explicit redef

noisesmith18:11:14

so you need to delete the var (or def to nil) to make defmulti actually do something

eoliphant18:11:18

didn’t pick it up

eoliphant18:11:28

ok thanks 🙂 lol

Audrius19:11:54

hi, who knows reagent? I have a question about TextInput class.

darwin19:11:21

@audrius try in #reagent

Audrius19:11:03

thanks . did not know it exists