Fork me on GitHub
#hoplon
<
2018-02-02
>
onetom01:02:35

@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)

flyboarder01:02:54

I have not yet written all the docs out

flyboarder01:02:23

they are not built, but are themselves a demo app

onetom01:02:25

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

flyboarder01:02:50

:thumbsup: would love the help 😉

onetom01:02:20

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

onetom01:02:07

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

thedavidmeister01:02:29

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

thedavidmeister01:02:50

but deferring to hoplon dataflow instead of what d3 does

thedavidmeister01:02:57

; 
(defn generator [] (.pie js/d3))

(defn pie
 [xs & {:keys [start-angle end-angle pad-angle]}]
 (camel-snake-kebab.extras/transform-keys
  camel-snake-kebab.core/->kebab-case-keyword
  (js->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->js xs))))))

thedavidmeister01:02:08

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

thedavidmeister01:02:44

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

thedavidmeister01:02:53

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

thedavidmeister01:02:02

@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

thedavidmeister01:02:25

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

thedavidmeister01:02:38

so that's some async

flyboarder01:02:12

@thedavidmeister that would be great for hoplon/brew

thedavidmeister01:02:17

hah, it will probably end up in wheel

thedavidmeister01:02:29

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

thedavidmeister01:02:45

of course i can do that anyway

thedavidmeister02:02:06

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

thedavidmeister02:02:41

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

thedavidmeister02:02:04

can't really just make up a standard without examples

onetom08:02:59

@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?

onetom15:02:43

@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"?

flyboarder15:02:39

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

onetom15:02:09

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

thedavidmeister15:02:00

i'm sure you could use material

thedavidmeister15:02:16

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

onetom15:02:39

ah, that's what u meant, got it

thedavidmeister15:02:52

yeah, read up ^^

thedavidmeister15:02:10

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

thedavidmeister15:02:59

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

thedavidmeister15:02:06

if you're interested..

thedavidmeister15:02:25

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

thedavidmeister15:02:06

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

thedavidmeister15:02:12

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

onetom15:02:30

with rather ugly names too...

thedavidmeister15:02:24

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

thedavidmeister15:02:36

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

onetom15:02:49

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