@micha: how are .hl files compiled in things like hoplon/twitter-bootstrap when i tried doing that it couldnt find the namespaces, i resorted to compiling the hl->cljs but that seems bad

@flyboarder: on the latest hoplon (alpha10) you need to add a :manifest true on the hoplon task before doing the build-jar. The .hl files will be compiled when used on other projects by the hoplon task.

You don't.

That's it.

This on the library. On the project that will use it you don't need the manifest option.

*this is on the library...

awesome thanks!

I know I’m a minority here with vim but it would be nice to have a vim-hoplon plugin with hl highlighting If I had time and if I was better with plugins I’d write one 😁

@tbrooke: i use vim

@tbrooke: https://github.com/micha/micha/blob/master/.vimrc#L252-L253

it's not perfect but that combined with some lispwords setttings does an ok job of things

@micha Duuh just realized it’s just either cljs or html but using your autocmd so I don’t have to type set filetype=clojure Thanks

🍻

@micha: what do you think about having dependencies in each of the demos instead of the current schema of centralized deps? It will be more beginner friendly imo.

totally

we can now make a boot task to help manage that if we want to

like a task we run on the repo to update deps

Yeah, I probably would still use grep, but we could do it 😉

haha if grep works then go with that

Hi, I'm playing with hoplon and hlisp

I am wondering what is hoplon's equivalent of ng-if based on the cell's content

Is there any?

what is ng-if exactly?

Based on the condition it removes or adds an HTML child element

@piotrek: this one? https://docs.angularjs.org/api/ng/directive/ngIf

Yes

we generally use the equivalent of ngHide

but you can do something like this:

(defn ng-if
  [show? child]
  (cell= (if show? [child] [])))

then in your program you can do

Sometimes (e. g. If the sub tree is big and for performance reasons) ng-if is better than ng-hide

(div :class "container" (ng-if some-cell (span "foop")))

@micha wow so simple

this does not deallocate the thing it's removing from the dom though

it keeps a reference to it and just shuffles it in and out of the dom

Right

if you're going to want to dynamically deallocate you will need to hand craft things, because js doesn't have weakrefs

so you're likely to end up with memory leaks unless you manually clean up

we generally try to organize our applications so we don't need to do this

I guess I could pass a function which would generate child element instead of the element

yeah but if that child element will hold references to things you could end up never actually deallocating them

True

Thanks for the info

if you have dom elements that have no state, meaning they're not being refered to by any closures etc

you can just do the cell= thing like this:

(div :class "container" (cell= (for [text seq-data] (span text)))

BTW new hoplon site and doc seems like a work in progress

where seq-data is some cell containing a seq of strings for example

thta will completely deallocate and reallocate

similar to react really

Do you have any ETA when it will have the basic info?

including a sort of dom diffing

it's a community effort, so we don't have a strict ETA

things are progressing very well i think

in a few weeks or months things should be well settled i think

Great

Yes, your example with seq-data will work for me

🍻

just watch out for leaks

we're thinking about ways to make cleanup easier, without resorting to lifecycle protocols

more like with-open than IDidMount

so you can use the seq-data way with more complex stateful custom elements that need to allocate cells internally etc.

I saw your presentation on clojutre conference where you compared hoplon approach to react (among others) like virtual DOM, life cycle etc

Can you point me to more details why hoplon approach is better?

there isn't a lot of documentation there

but the benefit is simplicity

react is complicated and sort of incidental complexity

pretending the dom is stateless involves all kinds of doublethink

the dom isn't stateless, and nobody wants a stateless dom

stateless dom is called <canvas>

and canvas isn't the thing you want to make webapps in, unless it's something very specialized

react is an immediate-mode rendering machine

but it's an API inversion, because the DOM is retained-mode

Document Object Model

in games like Doom or whatever you can make immediate mode rendering on top of pixels, because pixels are simple stateless write-only registers, basically

once your pixels can be interacted with by the user and contain their own state it's no longer immediate mode

this API inversion is why you need all the lifecycle protocols

and how to lifecycles compose?

they don't, really

lke you have IWillMount and stuff

Now it is more clear to me what you meant and it makes sense

but you start really trying to make composable things and you end up needing IBeforeWillMount

and IBeforeBeforeWillMount

and so on

because the lifecycle things happen asynchronously

you can't just compose functions anymore

lisp itself has "lifecycle protocols", but it's not something you really think about

it's done by composing functions and calling functions in a certain order

not by creating all the things in your lisp program in some map and then asynchronously calling lifecycle protocols on them

Hoplon looks very promising to me and I just can't wait for more documentation ☺️

like imagine if functions needed IWillBeApplied and IWasApplied etc

it would be madness

Yeah

basically any time i see any kind of lifecycle protocol i suspect shenanigans

One last question

shoot

What's the difference between class and do-class in hoplon?

I saw such convention in some examples

the :do-* and :on-* idiom has actually been removed

now it's just :class

that was an artifact from the beginning that we found wasn't really necessary

Oh so I saw some outdated examples

Thanks a lot for all the answers

yeah we're updating them

sure any time