I suppose there is not a good way to reload/eval .cljs.hl files or expressions therein via REPL connection? I have yet to figure out how to get this to work, and assume it has something to do with the hl -> cljs compile step

the reload boot task reloads everything, which might be good enough I guess, but I was wondering if it can get any better (can the feedback loop be tighter)?

or does it even make sense to do this because state can get all jacked-up?

so i hope this is an appropriate place to ask the question: does anyone know of work using Boot to create Nix packages for Clojure apps/libs? I'm struggling

boot likes to resolve and download bits of itself and bits of the app, but nix is very much of the opinion that it should download everything itself and build tools shouldn't need/be allowed network access

@telent, try #boot

ah, thanks

@cpmcdaniel - I’ve always used the reload functionality of boot-reload/figwheel when doing Cljs. I know some people here (e.g. Micha) don’t even use that, just plain browser reload. The hl -> cljs compilation step shouldn’t add any problems, you should have cljs files in the fileset (where the REPL sees them) immediately after you edit the .hl file. Not sure how that integrates with any tooling though

Yeah, the problem is with trying to eval expressions in the .cljs.hl buffer via REPL

for example, how to switch the REPL to the appropriate namespace

I like to eval small chunks of code as I build up to high-level functionality

you can ditch .hl files

yeah, I’ve been separating more core functionality (computational stuff sans dom things)

latest hoplon doesn’t need any special stuff

into .cljs files

(ns ^{:hoplon/page "index.html"} pages.index
  (:require [hoplon.core  :as h :refer [div ul li html head title body h1 span p button text]]
            [javelin.core :as j :refer [cell cell=]]
            [hoplon.jquery]))

especially for cell formulas that do a lot of mapping and filtering

@cpmcdaniel the .hl files are converted to cljs, I don't think you can properly eval the .hl version of the file

yeah, I’ve come to realize this. Just wondering if there is an alternative workflow, and the answer seems to be to move such code out to .cljs files

If you don't need the page macro I would stick with cljs files

Yeah I'm working on converting all my libs right now

I have a thought experiment to propose. Let's imagine you are writing a todo app using Hoplon, and you want different types of animations/transitions depending on how the model has been updated. For example, if the user adds the new todo item, you want it to appear instantly. If you load in a saved to-do list, you want the currently displayed to-do items to fade out and the new items to fade-in. How would you architect this? The challenge, as I see it, is that it doesn't make a lot of sense to track the "how to update" information as part of the model itself, because it doesn't really belong there. For example, if a newly-created item had an extra key-value pair in it {:transition :instant}, then when you save the model and re-load it, it would try to use the instant transition, when you want a fading process in that situation. So loading a model would have to edit all the transition types. Awkward. Would you create an atom for transition type and manually set it prior to each swap into a javelin cell, and have formula cells look in that atom? That seems awkward as well.

@puzzler you are looking for attribute providers

basically custom behaviours on an element in a generalized way

@flyboarder Possibly. I'm not sure I understand the explanation of attribute providers on the wiki. That seems more to be a description of whether to use goog or jquery. https://github.com/hoplon/hoplon/wiki/Attribute-Providers

@puzzler correct, our internal behaviours are provided by either jquery or goog, but you can use anything, the idea is when the input value changes (usually a cell) the behaviour will run again, so whenever the input changes you can apply a different animation

All the hoplon examples I've seen assume that you always use the same kind of animation to update a given input. I understand why that assumption is made -- the whole paradigm is based on the assumption that the view is a pure function of the model. But what if the transition style to the new view isn't a pure function of the model, and depends on context.

That's what I'm mulling over.

In some sense, I want to say "Run the propagation network right now, but during this run, any transitions executed by these formula cells should be such-and-such". binding a dynamic variable might work, but I'm not sure if the propagation is sufficiently synchronous for that to work.