Clojurians Log v2

@flyboarder that's exactly the kind of thing i meant, though if i look at http://oss.degree9.io/uikit-hl/#Card most of the components are empty (im having a look locally to see if it's just a deployment issue or it's just the library is that incomplete)

I have not yet written all the docs out

@onetom ^

they are not built, but are themselves a demo app

sounds like thats something i could help with if we were to adopt this library

:thumbsup: would love the help 😉

my biggest worry still is integrating a chart library...

we are trying to write a similar app, just with our own orderbook engine: https://app.radarrelay.com/

@onetom i've used a few different chart libs and ended up rolling with d3

but deferring to hoplon dataflow instead of what d3 does

e.g.

; <https://github.com/d3/d3-shape#pie>
(defn generator [] (.pie js/d3))

(defn pie
 [xs &amp; {:keys [start-angle end-angle pad-angle]}]
 (camel-snake-kebab.extras/transform-keys
  camel-snake-kebab.core/-&gt;kebab-case-keyword
  (js-&gt;clj
   (let [g (generator)]
    (oops.core/ocall g "startAngle" (or start-angle 0))
    (oops.core/ocall g "endAngle" (or end-angle wheel.math.number/tau))
    (oops.core/ocall g "padAngle" pad-angle)
    (g (clj-&gt;js xs))))))

arcs (j/cell= (d3-cljs.pie/pie vals :pad-angle (* wheel.math.number/tau 0.005)))

but some of the biggest changes we made in 7.x was improvements to interop with 3rd party libs

so if anything it should be easier to use any lib you want now 🙂

@onetom @flyboarder on the topic of widget library, i've got things that i could spin out but ultimately would like to adopt conventions and release a suite of components rather than endlessly pile them into something monolithic like my wheel repo

e.g. last night i made a gravatar integration for profile pics into hoplon and profile cells into javelin

so that's some async

@thedavidmeister that would be great for hoplon/brew

hah, it will probably end up in wheel

i mean, it would be nice as hoplon-gravatar or something

of course i can do that anyway

but we're talking about how to collaborate to some kind of "standard lib" here...

i suppose it's a bit chicken or the egg though 😕

can't really just make up a standard without examples

@onetom cool app btw

@flyboarder since i got inspired by the ADR philosophy after seeing @martinklepsch’s [work](https://github.com/martinklepsch/cljdoc), i feel i should ask why have you chosen UIKit? i haven't found any design document for it or a rationale which explains what sets it apart from other similar solutions. i see you used [cljsjs/material "1.1.3-1"] for blaze; what was wrong with that? why not continue the effort you already invested integrating that with hoplon?

@thedavidmeister https://material.io/ is already a "standard lib" with plenty of examples... is there any reason not to implement that? other than "material design is the new bootstrap and it's boring to look just like every other app"?

@onetom there are issues with the existing material design libs and the new material design web was not ready at the time

"new material design web"? what's that?

these things? https://github.com/material-components

i'm sure you could use material

it doesn't help establish any standards for building a hoplon component though

ah, that's what u meant, got it

yeah, read up ^^

@flyboarder was proposing some conventions for async state management, for example

but 7.x should make material easier to integrate for two reasons

if you're interested..

- no protocol overrides on DOM elements makes them behave better with 3rd party libs

- namespaced class attribute helps you to make standard wrappers around things like material

there's a lot of classes in material...

with rather ugly names too...

yeah, but it should be really easy to wrap them up in :class/material attributes now

and not have it clash with classes you might add for yourself

btw, what's the state of art for hot reloading? boot-reload or boot-figreload?

not sure soz