I think I'm missing something. Does anyone know why binding isn't working here at the end of the candlestick-chart function? That is, when *to-y* gets called inside candle it's still nil.

(def ^:dynamic *to-y* nil)
(defn candle [n ohlc]
  (j/cell-let [{:keys [open high low close]} ohlc]
   (let [x           (cell= (* n (+ candle-width candle-spacing)))
         wick-x      (cell= (+ x (/ candle-width 2)))
         body-height (cell= (max (- (max open close) (min open close)) 1))
         body-top    (cell= (*to-y* (if (> close open) close open)))
         border      {:stroke "black" :stroke-width 1 :shape-rendering "crispEdges"}]
     [(s/line :x1 wick-x :x2 wick-x
              :y1 (cell= (*to-y* high))
              :y2 (cell= (*to-y* low))
              border)
      (s/rect :x x :y body-top :width candle-width
              :height body-height
              :fill (cell= (if (< close open) "black" "white"))
              border)])))

(defelem candlestick-chart [{:keys [data] :as attrs} elems]
  (let [e                (s/svg (dissoc attrs :data))
        container-width  (cell= (.-offsetWidth  e)) 
        container-height ;(cell= (log/spy (.-offsetHeight e)))
        (:height attrs)
        data-high        (cell= (apply max (map :high data)))
        data-low         (cell= (apply min (map :low  data)))
        data-range       (cell= (- data-high data-low))]
    (binding [*to-y* (cell= #(* (/ (log/spy container-height) data-range)
                                (- data-high %)))]
      (e
       (for-tpl [[i ohlc]
                 (cell= (map-indexed vector data))]
         (candle i ohlc))))))

I tried with hoplon.binding/binding and cljs.core/binding

@jjttjj what if you put the binding inside the for-tpl?

@alandipert I tried that and it works, but doesn't that require a lot of extra work, when it should be a constant value for everything in the for-tpl loop? is that just unavoidable?

by a lot of extra work i mean computationally

yeah

it just confirms my suspicion without me needing to test 🙂

the problem is that the body of a -tpl is turned into a thunk

so candle is called asynchronously, basically

yeah i figured it was something like that

conferring here with micha

fix #1: make an arity of the candle function that takes the binding

err, takes a value

defeats dynamic binding to a degree of course, but in this particular case seems palatable

that's a preference anyway i guess, whether to pass or bind

fix #2 is the "real" fix

use hoplon.binding/bound-fn

to make a version of candle that uses the hoplon bound-fn magic to do what you're expecting

ok awesome thanks i'll try the bound-fn way and failing that just pass the value!

whether or not it makes sense to go bound-fn to make the binding work i think depends on your goals for organizing the bigger thing that we don't see in your snippet

gotcha. yeah I really need to get better at actually planning things out in general. thanks again

@john_tollison: we've used both trigger and cordova successfully without issues.

i doubt that javelin is the issue; that thing is rock-solid, in my experience.

i can share some snippets from a mobile project i did with hoplon if you'd find them helpful.

It's good to hear that javalin shouldn't be an issue. Code snippets may help. I should probably try to drill down a little more on specifically where things break down. I had this program I dropped in, all at once, and I was surprised when it sortof worked. I expected all or nothing. Let me do some more poking around and get back to you.

i've also used hoplon with http://trigger.io a couple of years ago

the only real issues i had was figuring out how to get the certs and signatures and stuff to work with the app store for ios

at the time http://trigger.io wasn't very well documented

but overall it was a pretty nice experience

we were also able to use a commercial jquery widget library that was pretty good

made nice controls for mobile

saved us a good amount of time probably

yes, I found out about http://trigger.io from a post you made on the discourse board, so I figured it shouldn't be too bad.

i haven't looked at it lately, are they still in business?

things seemed like they might have been a little shaky back then, not sure if they survived

they were the simplest one i could find

Yes, they appear to be doing ok.

I am seeing some action with cells now. I jumped to bad conclusions. Hopefully, I'll be able to work through other problems I'm seeing.

@flyboarder: as the local firebase expert, I hope you might know if there is any solution for developing offline or integration testing firebase. I saw there is https://github.com/katowulf/mockfirebase and https://github.com/urish/firebase-server but how can I deal with the storage or the auth clients?

For storage minio might work somehow...?

Hello, could you suggest any hoplon app examples handling authorisation (hiding functionality) to different parts of the application depending on the user role? It would be perfect if it would also show how to provide some parts as available without logging in

@piotrek i guess it depends how secure you need it to be

ultimately the hoplon side is JS so someone can always edit values to be whatever they want

the only way to truly protect data is to not send it to the browser at all

for that, i’ve had some success grabbing JWT tokens from auth0 and adding them to the headers that get sent to the server

JWT has the nice properties of being stateless and immutable, so it’s a reasonably natural fit

at that point i just use buddy https://github.com/funcool/buddy

Thanks @thedavidmeister. Yes, I am aware that user has full access to JS app code/state. That’s why I wrote “hiding functionality”. I am interested how to systematically solve that instead of sprinkling ifs everywhere. I know backend security area much better and yes JWT with buddy looks like a good solution

oh, if you just want to hide things visually then cell= is certainly the way to go

the higher up the DOM heirarchy you put the cell, the less if statements you’ll need

¯\(ツ)/¯

@piotrek when you say “different parts of the application”, do you mean routes/pages?

or individual elements?

individual elements

e.g. logged in users should see some additional content

but it’s also about top level routes - some “pages” shouldn’t be visible at all (and when accessed should display an error message)

i tend to split out elements to have a single concern and pass in all the cells they need to render

so I’d just pass in a logged-in? cell or similar

@piotrek are you using something like bidi to handle routing?

@piotrek fyi though, you don’t need if to visually hide something :toggle my-cell? will show/hide based on the truthyness of my-cell?

again though, that’s even less secure

it’s just a matter of css at that point

That’s ok as the backend will prevent unauthorised actions

It’s rather to not show what might end up with authz error

yup

So the user doesn’t have possibility to even try to invoke something that will complete with HTTP 403

(button :toggle auth? “Click me”)

if you want something more sophisticated, you could extend do!

to invent something like (button :admin roles “click me”)

toggle is implemented like this

(defmethod do! :toggle
  [elem _ v]
  (style/setElementShown elem (boolean v)))

you could do like

(defmethod do! :admin
  [elem _ rs]
  (style/setElementShown elem (contains? rs :admin)))

or something...

i dunno, what were you expecting @piotrek ?

Hmm, extending do! looks interesting @thedavidmeister

I could define :required-permissions attribute and define checking the actual available permissions in one place (my defmethod for that keyword)

Thanks @thedavidmeister

sure

i recommend that if you implement anything that “dials out” to a global state, implement that as fallback behaviour

it will make testing much easier

yeah, passing user details or permissions (or referring it directly from global var) in all the components would be a bad idea; using do! adds a level of indirection and decouples components

@onetom: hey, I haven't used either of those before

Usually because firebase is entirely hosted, there is no offline mode

It wasn't designed for offline first usage

they have offline mode support since may 2015 https://firebase.googleblog.com/2015/05/announcing-mobile-offline-support_93.html they went as far as saying: > Built from the Beginning for Offline

but what i really meant is a solution for local development and for automated integration testing. the guy who wrote firebase-server actually wrote it to speed up his test suite by 40%. https://firebase.googleblog.com/2015/04/end-to-end-testing-with-firebase-server_16.html

ok, i see the latest github issue is exactly this question: https://github.com/urish/firebase-server/issues/69

it's a bit scary for me not being able to dev offline... 😕 even for the whole google app engine, google provided an api compatible locally runnable solution... aws provides local dynamo db too. they don't provide local sqs or s3, but luckily there are open source solutions for that too.

@onetom: since firebase was a separate company before, I don't think it will ever get a local version unless it's open sourced

@onetom: what are you evaluating firebase for? Have you looked into parse server? Or feathers.js?

After building the last version of our prototype with firebase we moved to feathers for the production version current underway

somehow when i fire up boot dev on my project, for one of my hoplon pages it's insisting on serving up an old version of the page. despite numerous boot restarts. When i alter the file and save again, boot-reload re-compiles everything correctly and everything is correct. but then when i refresh the page it's back to the old version. somehow an old .html.js file seems to be sticking around. Does this sound familiar to anyone?

@flyboarder no, i havent even heard about feathers.js. parse as i remember was closed down or something, no?

im looking for some good authentication solution actually

i tried auth0 before but i was not satisfied with them at the end

stormpath seems like another potential one but they are not very developer friendly

plus im not very stoked about managing a python solution

@onetom I haven't tried it at all yet but I have a vague thought to give Amazon Cognito (their user auth service) a try eventually. Is that one on your radar?

yes, but cognito is quite complicated, that's why im looking into alternatives

@onetom: that was also my main concern I would suggest feathers

gotcha

Parse went OpenSource and closed the hosted company

I'm working on a complete cljs framework for feathers.js called featherscript

https://github.com/degree9/featherscript

@jjttjj in the past ~3 years im managing infrastructures with cloudformation, so im rather familiar with aws but it feels a bit too low-level for a lot of use cases.

@flyboarder thanks! i will dig into it very soon. is there any reason then to still use firebase instead of feathers?

If you want better mobile platform integration, firebase has crash reports for android iOS, the feathers mobile clients are a little behind right now

@onetom: here are the features and the supported platform for firebase https://firebase.google.com/docs/

Everything under grow and earn are mobile (iOS / android) only

I wanted auth and db on cljs, feathers let's me build everything in cljs from there, I also really like how the client mirrors the server

how do u do cljs backend?

with that node or npm boot task or what was that?

Yep

@onetom: right now, I'm using electron as my app is cross platform but I'll be using the boot-nodejs task for the demo app I'm building for ClojureRemote

boot-nodejs? not boot-npm?

google hasn't found anything on boot-nodejs

@onetom: https://github.com/degree9/boot-nodejs

I need to do some updates to it now that the new boot-cljs includes my edn generator

Ugh so much to document lol