This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-25
Channels
- # announcements (8)
- # aws (50)
- # aws-lambda (6)
- # babashka (25)
- # beginners (119)
- # bristol-clojurians (5)
- # calva (25)
- # chlorine-clover (23)
- # cider (6)
- # cljs-dev (125)
- # clojure (63)
- # clojure-austin (1)
- # clojure-belgium (1)
- # clojure-dev (48)
- # clojure-europe (11)
- # clojure-italy (2)
- # clojure-nl (5)
- # clojure-spec (3)
- # clojure-uk (66)
- # clojurescript (14)
- # core-logic (5)
- # datomic (13)
- # emacs (10)
- # events (2)
- # fulcro (37)
- # graalvm (11)
- # hoplon (95)
- # jobs-discuss (9)
- # juxt (11)
- # kaocha (16)
- # meander (13)
- # off-topic (24)
- # pedestal (4)
- # re-frame (36)
- # reagent (10)
- # reitit (15)
- # ring-swagger (5)
- # shadow-cljs (23)
- # spacemacs (2)
- # sql (13)
- # tools-deps (32)
- # xtdb (11)
Some random thoughts: start off by optimizing ease of use/access. Don't think too much about it until something becomes annoying and then step back and think if you could benefity from changing the granularity. That's the nice thing about hoplon, you can pretty easily adjust granularity
For example if you have a flat sequence of stuff that you will want to visually sequentually like in the todo app, it makes a lot of sense to just put it all in one cell
as the underlying data in the input cells change the data flows through the formulas and updates the UI
ok, i’m probably doing something wrong
i just mean that if you have a cell containing a sequence of todo items, for example, the sequence itself embodies important information
(defn checkbox [& {:keys [checked?]}]
(let [checked? (or checked? (cell false))
$checked? checked?]
(formula-of
[checked?]
(on
:mouse-down
(fn [_]
(swap! $checked? not)
nil)
(ui/checkbox checked?)))))
(let [test-checkbox (checkbox (cell false))]
(ui/run #(deref test-checkbox)))
(defn todo-item [& {:keys [todo]}]
(let [todo (or todo (cell {:description ""
:complete? false}))
$todo todo
]
(hlayout
(checkbox :checked? (path-cell $todo [:complete?]))
(textarea-view :text (path-cell $todo [:description]))
)))
(let [item (todo-item)]
(ui/run #(deref item)))
so my thinking was that “components” could receive cells as arguments
so they get auto updated when their cells change
and that basically works until you get to collections
my workflow so far has been , you make complex components out of simpler components
many of the hoplon examples don’t have very many defelem
components
my code is currently a little clunky, but I think it could be cleaned with some syntatic sugar macros
but you can do the usual lisp approach of doing the best you can with special cases where needed
i think lisp provides the best possible platform for making an imperfect world more sane
well, let’s you weren’t targeting the browser, what would you do differently?
what i mean is like in the browser you always need some weird extra div for padding or margins, things like that
javafx seems like it might be more regular, but i haven't used it enough to really know all of its secret faults
i think maybe webcomponents could be a big improvement in the browser, with shadow dom and css isolation
@smith.adriane have you heard of the amethyst and garnet projects in the 80s?
I have, but I haven’t revisited them in a while
i started messing with hoplon/ui (https://github.com/jumblerg/ui) again pretty deep recently, and i think he really nailed a ui model there (though it's ever changing and takes some work just to get running
yeah that is an example of an attempt for a full top-down solution to the composition problem
it looks like it’s focused on layout. does it have a story around events and state management?
for the visual side of things we went with UIKit (http://getuikit.com)
this lets us build components like this…
(modal/modal :stack true :container true
(modal/dialog
(modal/header
(modal/title "Patient Information"))
(modal/body :text/left true ::util/overflow-auto true ::section/muted true
(grid/grid :small true :grid {:masonry true}
::width/width-1-1 true
::width/child-width-1-2 true
(forms/form
(patient-basic-info patient))
(forms/form
(patient-address-info patient))
(forms/form
(patient-account-info patient))
(forms/form
(patient-insurance-info patient))))
(modal/footer ::text/right true
(button/button ::modal/close true :primary true
"Exit"))))))
@micha yes it fits in nicely with hoplon
we are building some enterprise medical apps with it right now
looks really spiffy
we took the theme from the uikit documentation website, the default style without a theme is pretty bare bones
but working with elements like cards and things is so easy
hahahaha
yeah our goal was to not have a designer at all, and let the devs just build
a nice spiffy UI helps to sell the underlying tech, even tho it’s not at all related
our users are doctors who are used to like windows 95 style apps, moving to the web is a challenge enough so it had to look appealing and simple
yeah I want to build out full docs but I dont have the time right now
so for
(forms/form (patient-basic-info patient))
what is patient
? is that a cell or POD?yeah patient is a cell in that example
the uikit-hl docs really need refresh, but the source is solid and in production
yea, looking through it. looks great
itself is a small hoplon app
I read in the hoplon docs about on!
stuff, but I don’t think I grokked it till I just saw the examples like
(defmethod uk-progress! ::progress
[elem _ v]
(h/do! elem :class {:uk-progress v}))
(h/defelem progress [attr kids]
(h/progress attr ::progress true kids))
hahah the less fun parts of app dev
somehow chrome remembered my password from more than 10 years ago before i disabled my facebook account
@micha whats wrong with the build?
this is the cleanest I could come up with 😕
(defelem todo-item [& {:keys [todo]
:or {todo {:description ""
:complete? false}}}]
(hlayout
(checkbox :checked? (path-cell $todo [:complete?]))
(textarea :text (path-cell $todo [:description]))))
(defn test-todo-item []
(let [item (todo-item :todo (cell {:description ""
:complete? false}))]
(ui/run #(do item))))
(defelem todo-list [& {:keys [todos]
:or {todos [{:description "first"
:complete? false}
{:description "second"
:complete? true}]}}]
(let [todo-count (cell= (count todos))
new-todo-text (cell "")]
(formula-of
[todo-count]
(vertical-layout
(horizontal-layout
(ui/button "add todo"
(fn []
(swap! $todos conj
{:description @new-todo-text
:complete? false})
(reset! new-todo-text nil)
nil))
(textarea :text new-todo-text))
(apply vlayout
(for [i (range todo-count)]
(todo-item :todo (path-cell todos [i]))))))))
(defn test-todo []
(let [todos (cell [{:description "first"
:complete? false}
{:description "second"
:complete? true}
{:description "third"
:complete? true}])
tlist (todo-list :todos todos)]
(ui/run #(do tlist))))
it does seem like javelin really wants to have a mutable DOM-like structure under the hood.
Well there is always some mutable layer under the hood, javelin doesn’t prescribe that part tho