Hey guys, I just put together a presentation for the Toronto Clojure Meetup, it would be awesome if you can flip through it and let me know if I can improve on it anywhere, cheers!

https://prezi.com/dysx7w7boqrl/boot-hoplon/?utm_campaign=share&utm_medium=copy

Welcome! @sherbondy

hey @micha @alandipert any chance I could get a review of https://github.com/hoplon/hoplon/pull/154?

alpha17 doesn’t support deref on events?

@thedavidmeister are you using the jquery attr provider?

actually, i’m not using alpha17 because it’s not on clojars

i was just reading the code

it should be in hoplon.jquery

(extend-type js/jQuery.Event
  cljs.core/IDeref
  (-deref [this] (-> this .-target js/jQuery .val)))

yeah it is

it needs to implement the protocol in te jquery Event type

so what’s the way to keep using jQuery moving forward?

and is that OK, or is the plan to remove it someday?

i don't think we plan to remove it, it's just optional now

you can do (:require [hoplon.jquery]) now

that will install all the jquery stuff

or if you use boot-hoplon the hoplon task will do that for you automatically

so if you have a project using boot-hoplon using a version of hoplon before alpha17, you can upgrade to alpha17 with no changes

yeah i have boot hoplon

well yeah, as i’ve been finding today, getting events to propagate on detached DOM elements is fiddly without jQuery

so if for nothing other than testing, i want to keep it

yeah i like jquery because it does what i expect most of the time

also it is still being actively developed

and it's easy to wrap because it's not object oriented

goog closure is very OO

mmm

so it has pointless enum types everywhere

etc

i guess to support the closure compiler

so do i have to require hoplon.jquery and hoplon.core everywhere?

because that will get annoying

if you use the hoplon task you don't have to do anything

no changes are needed to your code whatsoever

ok, yeah i do

so you should be good then

when do you think alpha17 will be on clojars, so i can try it out?

i can push it to clojars today

oh cool

are you sure the when-dom really isn't necessay?

i don’t know why it was there in the first place

it was there because certain events couldn't be added until the element was in the dom

ok, well if you can remember what events they are

we can update the test easy

i do not 😕

this is why test

#justsayin

i just don't want to break stuff

mmm i know

neither do i

but if nobody can remember what it was for, that’s tricky

i can look in the git history

that could be good

also i definitely can confirm that different events bubble differently or not at all while detached in different browsers

I think we should be safe for the most part with the when-dom changes

and jquery events and native ones behave differently in that respect too

but i wouldn’t expect an event that you bind to a detached element to break when you add it to the document

that would be weird

The issue there is when an event is triggered before it's added not after, something's need the parent to exist

right

what was the issue with with-dom?

was it interfering with something?

With the tests I believe

made it harder to test

how so?

because it means events don’t get bound until the element is added to the dom

so i have to manually add every element to the document before i can test it

but if you test it out of the dom you're testing a weird edge case, no?

and not the usual case

no?

i’m just testing the logic of my components

i think there must be a way to fix this without removing when-dom

is the tst/src/hoplon/on.cljs file an example of the issue?

the click-bind-test-div function?

ah no

actually that is rendered in a browser

and looked at with selenium

that was hopefully to demonstrate to you that removing with-dom does not break that case 🙂

https://github.com/hoplon/hoplon/pull/154/files#diff-34c2d91d36b80e7d4a953549243960f0R7

this bind-events test is a very simple example of what i might want to test

that would not work with with-dom

so the issue is you need it to be synchronous for testing and not async?

well, partly the async and partly the explicit checking that the element is in the document before binding an event

both are inconvenient

like why not add i to the dom after line 10 in that example?

well yeah, but i need to deal with async and attaching elements to the dom for every single test

(.append (js/jQuery "#container") i)

you could make a div-in-dom function

well there’s no #container but yeah...

instead of (h/div :click f)

you would do (div-in-dom :click f)

that would do like

more like (-> js/document .-body (.appendChild el)))

and also the async

i dunno, seems awkward to do this juggling for every single test shrug

one sec

well i just did this

(deftest bind-events
 (let [c (j/cell nil)
       f #(reset! c true)
       i (h/div :click f)]
   (-> js/document .-body (.appendChild i))

   ; Native event.
   (is (nil? @c))
   (.dispatchEvent i (js/Event. "click"))
   (is (= true @c))))

doesn’t work because of async i think

cljs test has async tests

yes but how do i avoid race conditions with with-dom?

hmm

oh derp i see it

one sec

oops just updated again

forgot to add to dom

but why is that with-dom on line 6 guaranteed to execute after the with-dom from on!?

because it's added later

the handlers execute in order

but it loops

ah yeah that's right

the first call is first, but if there’s a second call, who knows?

a settimeout that's longer than the polling interval perhaps

i mean testing stuff will be weird, in any case

still not guaranteed, what if i get a garbage collection or something?

i believe timeouts do execute in order

i mean, i’m running hundreds of tests that are all doing this

but then, i also add the overhead of all these timeouts to my tests 😕

like if you schedule a timeout and the thing is delayed, it will still execute them in order

just later

yes that’s true

testing stuff is always going to be weird when you're doing unit tests and not integration tests

like with selenium you have integration tests, which are like making a normal application

but i either have to add like 100ms to every test, which will really slow things down

yeah i know, but my selenium tests are already clocking in at 10+ minutes and i’m nowhere near done with my app

and they’re getting flaky

and also, it’s very hard to directly measure some things, like the state of cells

perhaps mutation observers

are the thing we need here

instpead of polling

yeah, if there’s an alternative that would be good

real shame we can’t remember what was broken in the first place 😞

but i was listening to your podcast from the other day, and one of you mentioned the two modes of developing with hoplon

“making the components” and “wiring everything up"

i am just wary or making changes just to support tests

that road leads to madness

well it goes somewhere...

we have nodejs apps at work that are insane because of stuff they did to support testing

right now it goes into silly things i have to do for selenium to see 1/10th of what is actually happening

well… i can live with attaching all my dom elements manually before testing them if i have to

but i don’t want race conditions or arbitrary timeouts in the tests either 😕

we could fire a in-dom event when the when-dom does its thing

here https://github.com/hoplon/hoplon/blob/master/src/hoplon/core.cljs#L280

then you can put an event handler on that

actually that would be amazing

and run your tests

because i need that elsewhere other than tests

like for example, i have a js library that needs a canvas element to work on

I don't want to suggest life cycles or anything but maybe it would be good to emit events so elements act more like they were created from HTML

just knowing that something is “done being built” would be helpful

both for testing and working with 3rd party libs

there is no way to really know when a thing is done being built

because we're in lisp

a dynamic language has no way to know when you're done programming

because you can even be doing stuff in the repl

sure

but i do think that when we poll like in when-dom we are introducing nondeterministic behavior

what about “hoplon core is done messing with this element”?

so the event would totally make sense

well hoplon is extensible

hoplon doesn't know when it's done

you can be hoploning at the repl

mmm

just in general there isn't a way for lisp programs to know much about what their end goal is

but it really is not fun to have to fall back to timeouts to hope an element is ready to pass off to a lib/test

yeah that's a unique case though

we use timeouts in the when-dom business because of browser limitations

but an event that fires when the thing is in the dom would solve that

i feel that if you extend hoplon with something that introduces async it’s up to you to manage that

but what hoplon ships with should be manageable “out of the box"

i do get what you’re saying about being able to change things dynamically

well you definitely shouldn't be making applications that depend on being able to order your event handlers via reflection

if you're running into race conditions with when-dom in your application i'd say you're doing something crazy and there is certainly a simpler way

usually lifting whatever it is to one level of abstraction higher

testing is a good example of what you don't want to do in an application

like in tests you're exposing internals of different levels of abstraction and intermingling them

which you definitely don't want to do in the application

yeah

i probably could solve the lib problem using when-dom

but i am a bit concerned about “stacking” when-dom

we can fix that

what we do is make a vector of callbacks

attached to the element itself

when you call when-dom it creates that vector or adds a handler to it if it already exists

and when the thing is in the dom it fires all the handlers

in order

if you add a handler via when-dom when it's already in the dom it will do process.nextTick or whatever it is in the browser

or settimeout 0

then there is no nondeterminism

i think that would be a good improvement

then i’d be willing to try your suggestion of wrapping the tests in when-dom

ok cool i'll get something going here

should be straightforward

yay

should i paste this conversation onto the github issue?

that would be good for future-us to have when we wonder why we did this 🙂

Browserify solved next tick already, maybe we can use this approach? http://timnew.me/blog/2014/06/23/process-nexttick-implementation-in-browser/

interesting

We can also skip their ie8 portion

do we not support ie8 anymore?

or we just do settimeout for ie8?

I think we should move all the ie8 stuff to its own namespace otherwise we will have compatibility patches in core

But a fallback to set timeout is probably best

yeah this code you linked to looks fine

it falls back to settimeout and stuff

I'm sure it can be cleaned up as cljs in a smaller fashion

sure

i think for when-dom we might actually want a timeout though

since we will want to poll

Would the event emitting not work?

we don't want to prevent other threads from running though

like process.nextTick in node can be used to make an infinite loop that monopolizes the cpu forever

so if you're waiting for other code to do stuff you don't want to use that

at least you don't want it to call nextTick itself

ok if there are no objections i will merge boot-hoplon PR in hoplon

actually i do some stuff first

@micha: on an unrelated note, did you have a chance to look at the presentation I linked to? I'm just wondering if you see anything that's wrong 😜

ah one sec, will look

aight im off

ok i shouldhave something to show in a little bit

i'll make a PR

@micha: that is an interesting piece of machinery in #156

this presentation is prety slick @flyboarder

Thanks!

the middleware concept is difficult to explain in a slide i think

maybe I should show the cascading portion in another one

"returns next-handler + fileset" could be confusing

but then again the whole concept is kind of confusing until you do it

yeah perhaps a code demo there, show the whole (apply next-handler fileset)

as the result

perhaps like "returns a fileset, can call the next handler" or something?

the pipeline is a sequence of steps

each step transforms a fileset

each step can decide whether to call the next step or not

ok, since the timing can be controlled and such

right

sounds good

the actual middleware and whatnot is implementation detail to make it work in lisp

excellent, yes

actually that might be bad saying it returns middleware and returns a fileset

yeah the task itself returns middleware, and middleware returns a handler, and the handler returns a fileset

lol

head explode

awesome yes

@flyboarder Do you have a code example with that slide? It may help a lot to understand what's going on if people can read code. I think I can only understand the slide because I'm already familiar with what that does.

yep, im presenting a demo of a freecodecamp react app that I converted to hoplon, thats a previous presentation

I mean of one boot task for the concept of middleware. But looking at your presentation it's a part too small to be able to give lots of details.

yeah the boot part is mostly an overview of whats going on, then it goes into hoplon with a bit more detail about the inner workings of that, followed by a visual app

the idea is to express that everything is usable on it's own, but cover the concepts which make it awesome to use together

Yeah, there is only so much one can explain with limited time. 😉 It's a really nice presentation. I always get a bit dizzy looking at prezi stuff lol.

yeah plus i dont want to spend too much time explaining and not demo

@jumblerg issues related to deps.cljs resolved in my PR (#155)

@micha: awesome, many thanks!

deps.cljs does appear to work in the project as well as in jars

so that's good

in that case, maybe i'll throw in a cigar.

lol

cubans are legal now

and quite delicious with a congnac

you've been upgraded

i ended up putting in a special case

cause otherwise you do want to see exceptions if a namespace is malformed

eh, nvm, back to beer then in that case. 😄

so tehre is a bogus-cljs-files set in there now

i think that makes sense, for the next person who decides to invent a new kind of cljs file.

yeah

it does seem that the boot-cljs task could take the initiative to clean this up, and encourage the user of a deps.edn file or something with a depreciation notice when someone tries to ram a deps.cljs file down the pipe.

we don't have to break ppls shit, but i'm all for annoying them.

lol

don't worry i'm sure they're annoyed enough already

maybe toss a few alerts at them for good measure, i see my old friend boot speak was generalized to do this.

^thoughts?

what would the multimethod look like?

i mean like what does it dispatch on?

mk!

Which would let us replace the different ctors for SVG and factor out ie8 patches from core to its own ns

I also see this opening up to other frameworks creating hl compatible elements

Like jquery element for example

Then it's always a jquery element for the jquery provider instead of wrapping it each time

I think it would dispatch on the element itself when it's constructed

hm i dunno

i dont know if that would work tho

Hello, I have a couple confusions about using hoplon/castra with multiple routes. I'm using the template from here https://github.com/tailrecursion/hoplon-castra-template and I want to have a / route and a /comments/:id route. So, I just copied the / route and changed the route specification and the file name. However, when I navigate to /comments/0 or something, it doesn't seem to be able to find the new template.

Hmm, I think I figured it out, I had to put the complete path relative to the site root inside (page)

Now, I have to figure out how to pass data from defroutes into the template.