This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-17
Channels
- # admin-announcements (3)
- # beginners (15)
- # boot (5)
- # cider (25)
- # cljs-dev (9)
- # cljsjs (5)
- # clojure (30)
- # clojure-belgium (20)
- # clojure-boston (1)
- # clojure-greece (1)
- # clojure-japan (3)
- # clojure-russia (17)
- # clojure-uk (2)
- # clojurescript (49)
- # clojurewerkz (2)
- # cursive (5)
- # datomic (1)
- # emacs (1)
- # euroclojure (1)
- # hoplon (155)
- # jobs-discuss (17)
- # mount (6)
- # off-topic (1)
- # om (87)
- # proton (2)
- # re-frame (3)
- # remote-jobs (4)
- # spacemacs (2)
- # untangled (12)
I'd be curious to know what he thinks too, afaik he hasn't looked at it
I'm at the edge of my seat right now
@dnolen: I've just listened to your interview on Cognicast today and you mentioned how great is the "single atom as UI state" concept but at the same time you needed cursors (kinda like lenses) to make it manageable. Then om/next has a query language which replaces cursors. I was wondering how it all relates to Javelin for example which seem to solve such issues very elegantly in a non-UI programming specific manner. I'm curious about your opinion, because I would like to introduce Hoplon to a company, who has started using React's http://material-ui.com and they see the merits of om/next, but I feel Hoplon would be even simpler for them. I don't know enough about om/next yet to understand and explain the pros and cons, so it would be great to hear what do you have to say.
I've introduced Hoplon to the company I work for atm about ~1.5yrs ago, instead of om and reagent (to replace a nodejs backend & a spaghetti frontend) and I found it really easy to teach it to new colleagues.
@onetom: are you still interested in remote pairing btw? i had an idea for something that i think could be really fun to work on
attaching source code to defc= and cell= at compile time using the Var meta stuff
then combining that with d3 to show the cell graph w/ sources
like http://tailrecursion.com/~alan/ttt/basic.html but actually useful heh
@alandipert: of course im interested. we just had a 3hours mutual screen sharing session w jesse last nite about hoplon/ui.
well that's why i need your help
i think the changes will be very small we just need to identify them
also could use help with API decisions like how to turn on debugging compile mode
it would be interesting to hook into the hoplon IFn thing to link a dom element in the dev inspector to the cells that are wired to it
also i just want to pair with someone really far away and set my own pairing distance record
im about to go now, i'll be back later and throw out some times
could also look into dirac/cljstools that https://github.com/binaryage produced
we are using the https://github.com/binaryage/cljs-devtools didnt go as far as setting up dirac because it's too much hassle, since we would need to set it up on several machines
@micha, @alandipert: here’s something i sketched up on the train, would love to discuss the merits of this approach (i.e. wrapping/extending dom elements to expose a general, maplike interface to the dom).
granted, there are some mismatches (eg, how do we handle IMap/dissoc), but these same mismatches exist when we build an spa around a model we loaded from the server.
mutation observers are the glue that let us complete the read (from the app’s perspective, write from the ui) half of the circuit that could make this possible.
when we need to do something with any of these IAssociative maplike things, we can then just drop them into a reference type, atom, cell, etc.
so for a given element e
you want to be able to obtain a cell with the value of e
's width, for instance?
i think this sketch could help to explain how we implement functions like dissoc: say we dissoc
a property like :height
from the model, but next time the browser renders, since the browser would have calculated some height for the property in question, a command would add it back to the model..
so i can’t drop it into a cell, for example, and have it trigger formula cells bound to it to calculate other values when it gets rendered
if we remap them to a clojurelike api, then they work with other things like reference types
right so it makes sense to have a function that will take an element and a property as arguments and return a formula cell
would be nice to be able to not only (js/Element :height 200)
, but also (cell= some-width (+ 200 (:height (cell js/Element))))
actually, the former should get the height then default to 200 of no height was there
the reason we use maps, vectors in clojure istead of custom models made of javabeans is because the interface is general, i wonder if the same principles apply here
to me, that is like constructing the document model from beans, while our app model is build of maps, vectors, etc.
if they’re more uniform, perhaps they line up more nicely an there’s less of a mismatch
i’m not saying we should do this, i understand your perspective, is dangerous to do things that imply certain semantics when, in fact, they’re different in subtle but significant ways
i haven’t thought this all the way through, but it thought it would be an interesting exercise to do it
yeah. unfortunately, i’ve just started a conversation i find fascinating, and one that if i continue, will cause me to miss my deadline tomorrow morning.
wanted to toss some ideas onto the heap while i was riding the train to my office. can we pick this back up in the next couple days?
i do enjoy this socratic process, really helps to think thinks through and flesh out ideas.
@jumblerg: have you looked into garnet at all btw? the CL windowing toolkit?
i haven't studied it very deeply but there might be things to mine there
it uses prototypal inheritance and reactive fields on the instances, so they came up with something browser-like
they call their cell things "constraints"
https://www.youtube.com/watch?v=wc8A0woo0X4 is a good intro, there are papers etc
@alandipert: nope, but i’ll definitely look through it.
@alandipert, @micha: which reminds me, the old flex framework i used to use back in the day had some interesting ideas just before flash was killed off. one of them was the introduction of component skins. the logic of the component was written imperatively in actionscript, which defined the behaviors and different states og component. “skins” could then be designed for each component using an svg like vector image, which could be exported by any designer from photoshop, illustrator, etc.
i was thinking about this wrt hoplon/ui; since the first step is to negate all the default styles of a component before passing it to the box model wrapper (then implementing them in a more general fashion on another div), i was thinking that this could be done just as easily in svg.
here’s a sample flex skin for a flex dropdown button; i’ve highlighted the states: https://github.com/apache/flex-sdk/blob/eec643c453a3a1bec6ea3352b0c94ec81d36b2d6/frameworks/projects/spark/src/spark/skins/spark/ToggleButtonSkin.mxml#L94-L103.
the foundation the flex team was building on left much to be desired, but they had some interesting ideas: what if, instead of trying to interface with designers at the html/css level, we did it at the svg level instead?
so you could use svg for the UI skeleton, layout, buttons, etc, and html for displaying documents
that is interesting
i need to rework all these components, been focused on layout. but in the first step, properties are passed to the component to negate the defaults because they’re unmanageable.
i am reminded of the bad/good old days of table layout
:thumbsup:
the middle div, right now, handles the styling https://github.com/hoplon/ui/blob/master/src/hoplon/ui.cljs.hl#L406-L426
but there could just as easily be an svg overlay rolled into there for that purpose instead
the “picture” of the component could be implemented in as an svg overlay, background i think.
maybe using absolute layout, constrained to the size of the component, one z-index behind
also, this would help make this easier: https://github.com/hoplon/hoplon/pull/122