Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2016-05-19

Channels

#hoplon
<
2016-05-19
>
dm311:05:45

seems correct

micha14:05:53

@thedavidmeister: i don't think dom elements are a problem for memory leaks

micha14:05:13

the problem is when you create formula cells that refer to cells outside the template

micha14:05:23

those formula cells cannot be garbage collected

micha14:05:01

and if the dom elements contain references to those cells, for example in event handler closures, then the dom elements can't be collected either

micha14:05:27

so the example you have in the doc there would be ok, no memory leaks

micha14:05:33

but this would have a memory leak:

micha14:05:28

(defc red? true)
(defc fat? true)

(html
  (body
    (div
      (cell=
        (if red?
          (div :class (cell= {:width (if fat? 100 20)}) :id "red")
          (span :class (cell= {:width (if fat? 100 20)}) :id "black"))))))

micha14:05:38

the reason why this leaks memory is the :class attribute that's bound to a formula cell that references fat?

micha14:05:04

now this formula cell cannot be GC until fat? is

micha14:05:44

there is a watch on the formula cell that's created by hoplon, which updates the class name of the element wnever the formula cell updates

micha14:05:08

so this watch callback closes over a reference to the element

micha14:05:22

now the element can't be GCuntil the formula cell is GC

micha14:05:02

without the formula cell the divs and spans would be GC just fine when there are no remaining references to them

thedavidmeister14:05:14

@micha ta, i’ll review this, digest it and update the wiki 🙂

micha14:05:34

awesome writeup btw 🙂

micha14:05:51

is it ok if i update the memory leak part?

thedavidmeister14:05:36

i sort of fumbled through that bit

thedavidmeister14:05:07

@micha i have a habit of writing tests and docs as a way to learn, but i don’t always get it right 😉

micha14:05:09

i was just nitpicking, really 🙂

thedavidmeister14:05:48

nah, it’s important

thedavidmeister14:05:48

the docs have to say the right thing

onetom14:05:11

@thedavidmeister: i was just wondering today if there is any docs on these latest *-tpl functions, because it seems i should start teaching hoplon in my new job very soon. so, thanks a lot for the docs!

onetom14:05:15

actually i will teach clojure via hoplon probably

alandipert14:05:18

@onetom: you have a new job? congrats

thedavidmeister14:05:38

yeah, i’m teaching clojure at work through boot

thedavidmeister14:05:56

using boot tasks to make reports 🙂

micha14:05:37

ok i made update

thedavidmeister15:05:39

seems good to me

onetom15:05:37

@alandipert: yeah, i thought i mentioned it already. building a property development investment management web app. young, small startup. 4 people at the moment. 3 of us are coding too. physically it's close to exicon too, so i still can walk over any time to have lunch with the hong kong clojure community 🙂

onetom15:05:23

@micha: there is a (defc wide? true) missing from your example, no?

micha15:05:54

yeah wide? is sort of implied to be defeined elsewhere

micha15:05:02

like red?

jamieorc15:05:16

@onetom: I read wide?’s defined elsewhere, but it might be good for those unfamiliar to have it

onetom15:05:33

yeah, that too. though it's important that they are cells, otherwise there is no problem.

micha15:05:42

that's a good point

micha15:05:00

if wide? isn't a cell then there is no leak

jamieorc15:05:30

it’d be good to call that out so there’s no confusion among new learners coming in

onetom15:05:49

also, would this be a solution / workaround? 

(let [width-css (cell= {:width (if wide? "100px" "50px")})
  (cell=
    (if red?
      (div :id "red" :css width-css)
      (span :id "black" :css width-css))))

onetom15:05:17

im also wondering, shouldn't we avoid formula cell definitions within formula cells, or that's not really a problem on its own? :thinking_face:

jumblerg15:05:35

@micha: is there a way we can remove all the associated watches when a child is removed from the dom? maybe stick the generated keyword passed to watch on some elem metadata then call unwatch when removeChild is invoked?

micha15:05:38

yeah but there could be other things

micha15:05:57

i think the "domains" concept might be the best solution

micha15:05:18

where you explicitly assign things to a domain which is collected as a whole

onetom15:05:47

@thedavidmeister: how about renaming this wiki page to: > Dynamic DOM manipulation a.k.a. Template Macros so the url is more readable?

micha15:05:22

@onetom: the let binding won't help there, because of the watches

jumblerg15:05:23

was also looking at doc fragments

jumblerg15:05:35

as a sort of transactional unit

jumblerg15:05:25

maybe to establish boundaries of a "domain"?

micha15:05:38

@jumblerg: yeah there are two things: the domain as a sort of reference counting scheme, and the lifecycle of the domain which would be something you'd associate with dom structures like for-tpl or something

micha15:05:25

maybe some kind of mutation observer thing

micha15:05:47

but i haven't run into a situation where the complexity was really needed

micha15:05:01

i just use loop-tpl and so far have been able to do that in all cases

micha15:05:12

even tree-like structures

jumblerg15:05:55

gotit, you just don't have a case for the raw cell in the child since the possibilities are typically finite

micha15:05:11

yeah i think in all cases they will be finite

micha15:05:28

or at least extensible at runtime via multimethod etc

flyboarder18:05:21

@micha is hoplon still doing things to elements removed from the DOM outside of hoplon?

micha18:05:54

@flyboarder: how do you mean?

flyboarder18:05:26

Is it still removing js listeners and such?

flyboarder18:05:11

hmmm, then my problem is elsewhere… thanks!