@dm3: is there a repository of cool defelems somewhere?

the only one I know is hoplon/demos

in github

ok cool

is there a way to do :pre and :post conditions with defelem?

If it doesn't support them it should imo

it didn’t seem to work for me

but i would love for a second opinion

i like that you can get the compiler to remove them if the tests end up affecting performance

Yeah, doesn't look like it does. You could do it with a wrapper macro, otherwise a patch would be welcome

I might take a stab at doing it in hoplon this morning

Always good to limber up for the day with a little macrology

if you manage to do it that would be awesome

but no rush

i wouldn’t even be looking at what i was going to use it for until the weekend

ok this is more involved than i thought 😅

definitely doable tho

geez, if you’re saying that, i have no chance

aha no it's not that bad

doing it in hoplon is a little tricky because it needs to still handle not having pre/post

but you could also do it in a wrapper macro that wraps defelem

which would be a little easier since you don't need to support the non-pre/post way

what do you mean handle not having it?

like, pre/post conditions should be optional

which means conditional behavior inside at least hoplon.core/elem macro

oh yeah, that’s true

but i’d want that too

maybe it could be called definitelyelem

lol

worst

haha

hey, maybe this is a simple q, maybe not

but what does page actually do?

also there's an issue of elem functions being called with nil when items are removed from loop-tpl, so the pre conditions will fail (depending on what you check)

@thedavidmeister: boot-hoplon looks at it to figure what to call the html file, then turns the rest of it into an ns

the sausage is made in https://github.com/hoplon/boot-hoplon/blob/master/src/hoplon/boot_hoplon/compiler.clj

hmmm, do you guys normally have different pages

or one page that changes depending on something in the URL or similar?

i just noticed that my main page is noticeably slower than my other page that i made

i think it’s todo with the way i’m doing caches

i’m wondering if it would be a good idea to do a cell= on the URL fragment

and turn each thing that is currently a page into a defelem

and swap between them that way, and just put all of the caches on index.html

went another way with it - an inline conditions macro:

(defmacro with-conditions
  [conditions & body]
  {:pre [(map? conditions)]}
  (if-not *assert*
    `(do ~@body)
    (let [ret (gensym "ret")]
      `(do ~@(for [pre (:pre conditions)]
               `(when-not ~pre
                  (throw (ex-info "Precondition failed" {:pre '~pre}))))
           (let [~ret (do ~@body)]
             ~@(for [post (:post conditions)]
                 `(when-not (let [~'% ~ret] ~post)
                    (throw (ex-info "Postcondition failed" {:post '~post}))))
             ~ret)))))

(defn foop [x y]
  (with-conditions
    {:pre [(even? x)] :post [(odd? %)]}
    (+ x y)))

that lil guy respects *assert* and so elides the checks conditionally

ooh

nice

bonus points for showing expected vs. actual

like what is does in testing 😛

ok yay

i think navigation cell is going to work

(def current-hash (cell (.. js/window -location -hash)))
(cell= (set! (.. js/window -location -hash) current-hash))

(c/defelem nav-link
  [attributes children]
  (let [{go :data-go href :href} attributes]
    (c/a
      :data-current-path (cell= (= go url/current-hash))
      :target (if href "_blank")
      :click #(reset! url/current-hash go)

      attributes
      children)))

(cell=
    (if (= url/current-hash "#style-guide")
      (style-guide/style-guide)
      (index/index))))

how cool

can’t believe i only just thought of that lol

anyway, i g2g

nice!

hmmm, making the site sluggish for some reason

i suppose i’ll have to play around a bit more

catch

Is there a command line option to set BOOT_EMIT_TARGET=no/yes

or better tie to a deftask?

@symbit: you could probably do something like export BOOT_EMIT_TARGET=no; boot do some tasks

but you might be better off setting that in your bashrc or .profile or whatever runs when you start a shell

boot dev I need BOOT_EMIT_TARGET=no

boot uberwar I need BOOT_EMIT_TARGET=yes

the idea with the env var is that automatic target dir is deprecated. so you would always have boot_emit_target set to no. when you make your uberwar you do boot uberwar targt

target

the target task is the standard way to emit artifacts to a target dir

On windows when running boot dev for a hoplon app I need 'NO' so that my web page will refresh correctly on source code changes.

When building the uberwar I call target. Are you saying target ignore what the state of BOOT_EMIT_TARGET is?

right, boot_emit_target is an environment var that when set to no will not automatically generate a target dir. when you explicitly call the target task, it's not automatic because you're telling boot what to do

i know that there have been certain, um, idiosyncrasies with windows but i don't know if they affect your mileage for this case. maybe check with @laforge49

I test a bit more and let you know. Thank!

@raywillig No dice. I removed BOOT_EMIT_TARGET=yes from boot.properties. The uberwar task runs fine creating the target dir.. But when running boot dev, load the page and make a change, java.nio.file.AccessDeniedException while trying to update \indexDOT_html.js

I attempted to add (set-env! "BOOT_EMIT_TARGET" "no") at the top of the dev task but it doesn't work.

trying one more thing...

@symbit: BOOT_EMIT_TARGET needs to be set outside of boot. it's an env var

so if you're using boot.properties (I think) you'll want to set BOOT_EMIT_TARGET=no

just removing yes is not the same as no

@thedavidmeister: i know im a bit late to the convo, but hoplon already has route-cell which returns a formula cell which auto responds to hash change.

sorry, @raywillig had no then changed to yes before 2.5.5 and then target change. So keeping it no works for both, however I see the reload is not working on the browser side.

ahoy @scot-brown, welcome

Thank you!