Fork me on GitHub
#hoplon
<
2016-04-17
>
onetom00:04:27

Is there any public source where dnolen expressed his opinion on Hoplon?

alandipert03:04:13

I'd be curious to know what he thinks too, afaik he hasn't looked at it

jumar04:04:12

Maybe we can ask him: @dnolen, what’s your opinion on Hoplon?

levitanong04:04:34

I'm at the edge of my seat right now

onetom13:04:24

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

onetom13:04:18

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.

alandipert14:04:48

@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

alandipert14:04:53

attaching source code to defc= and cell= at compile time using the Var meta stuff

alandipert14:04:22

then combining that with d3 to show the cell graph w/ sources

onetom14:04:07

@alandipert: of course im interested. we just had a 3hours mutual screen sharing session w jesse last nite about hoplon/ui.

onetom14:04:51

although the topic sounds quite adavanced. not sure how much could i contribute 😕

alandipert14:04:35

well that's why i need your help simple_smile

alandipert14:04:11

i think the changes will be very small we just need to identify them

alandipert14:04:25

also could use help with API decisions like how to turn on debugging compile mode

micha14:04:55

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

alandipert14:04:57

also i just want to pair with someone really far away and set my own pairing distance record

onetom14:04:06

when would it be good for you?

micha14:04:14

like select a chain of cell ancestry ending at the element

onetom14:04:55

im good for a few hours now

alandipert14:04:24

im about to go now, i'll be back later and throw out some times

onetom15:04:10

ok. im very interested

dm315:04:42

interesting ideas

dm315:04:06

could also look into dirac/cljstools that https://github.com/binaryage produced

dm315:04:11

integration

onetom15:04:59

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

jumblerg16:04:25

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

jumblerg16:04:38

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.

jumblerg16:04:06

maybe our document model isn’t so different from our app/data model

jumblerg16:04:58

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.

jumblerg16:04:31

they also have a log that make it easy for us to emulate versioning, persistence

jumblerg16:04:28

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.

micha16:04:29

so for a given element e you want to be able to obtain a cell with the value of e's width, for instance?

micha16:04:47

that will update as the element changes?

jumblerg16:04:23

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..

micha16:04:07

js elements are already hash maps

micha16:04:16

(.-width e)

micha16:04:21

or whatever

jumblerg16:04:47

yeah, but the interface is mismatched with clojure’s.

micha16:04:50

(aget e "width")

micha16:04:36

is there a benefit other than cosmetic?

jumblerg16:04:40

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

micha16:04:53

but that's a limitation of the platform

micha17:04:10

implementing IAssoc or whatever won't help there

jumblerg17:04:13

the apis are all there, through things like mutation observers, they’re just a mess

jumblerg17:04:41

if we remap them to a clojurelike api, then they work with other things like reference types

jumblerg17:04:54

not cosmetic at all

micha17:04:07

right so it makes sense to have a function that will take an element and a property as arguments and return a formula cell

micha17:04:24

that doesn't seem ot have any connection to IAssoc though

jumblerg17:04:09

would be nice to be able to not only (js/Element :height 200), but also (cell= some-width (+ 200 (:height (cell js/Element))))

micha17:04:29

or (defc= some-width (+ 200 ~(observe e :height)))

jumblerg17:04:57

actually, the former should get the height then default to 200 of no height was there simple_smile

micha17:04:02

observe would be a function that does the mutation observer thing to return a cell

jumblerg17:04:22

would also work, but the interface is more dom-specific

micha17:04:46

the whole concept is js specific

micha17:04:11

observe would work on anything that mutation observers work on

jumblerg17:04:32

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

jumblerg17:04:00

to me, that is like constructing the document model from beans, while our app model is build of maps, vectors, etc.

micha17:04:07

i have just regretted doing that in the psat

micha17:04:13

with hoplon even

jumblerg17:04:17

if they’re more uniform, perhaps they line up more nicely an there’s less of a mismatch

micha17:04:19

hoplon used to implement IAssoc

micha17:04:28

but it turned out to be a very leaky abstraction

micha17:04:00

and no benefit as far as i can see between (.-foo obj) and (:foo obj)

micha17:04:16

like why doesn't clojure do this itself?

jumblerg17:04:25

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

micha17:04:37

rich could have implemented interop that way

jumblerg17:04:42

i haven’t thought this all the way through, but it thought it would be an interesting exercise to do it

jumblerg17:04:48

good point, yeah

jumblerg17:04:28

on the other hand, be have bean

micha17:04:29

there is the whole thing with (.foo obj) vs (.-foo obj)

micha17:04:40

which is way more important in js actually than java

jumblerg17:04:43

to mapify/generalize the object interface

micha17:04:50

because in js things are many times used both ways

jumblerg17:04:02

and maybe we can beanify our document model simple_smile

micha17:04:02

unlike java where a member is iether a proeprty or a method

micha17:04:11

in javascript they're both sometimes

micha17:04:25

well that's the idea behind react really

micha17:04:38

to express the mutable dom as a succession of immutable cljs maps

micha17:04:48

but i don't think it works because it's a leaky absrtaction

jumblerg17:04:48

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.

jumblerg17:04:41

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?

micha17:04:50

sure anytime

jumblerg17:04:52

i do enjoy this socratic process, really helps to think thinks through and flesh out ideas.

micha17:04:43

perhaps IAssoc makes sense if it returns the cell

micha17:04:04

and not as the equivalent of interop property access

micha17:04:20

(def height-cell (:height some-element))

alandipert19:04:34

@jumblerg: have you looked into garnet at all btw? the CL windowing toolkit?

alandipert19:04:42

i haven't studied it very deeply but there might be things to mine there

alandipert19:04:32

it uses prototypal inheritance and reactive fields on the instances, so they came up with something browser-like

alandipert19:04:43

they call their cell things "constraints"

jumblerg20:04:10

@alandipert: nope, but i’ll definitely look through it.

jumblerg20:04:02

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

jumblerg20:04:34

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.

jumblerg20:04:14

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?

micha20:04:56

what about text content though?

micha20:04:08

that's the main problem with svg in browsers

micha20:04:15

you can't nest html elements inside them

micha20:04:25

so to get text to flow well it's difficult

jumblerg20:04:38

you can overlay easily enough if the box model in ui provided for it

jumblerg20:04:57

the skins should not be containers, i agree with you there

micha20:04:57

oh that's a very interesting idea

micha20:04:26

ideally you would be able to put a html div inside an svg element

micha20:04:51

so you could use svg for the UI skeleton, layout, buttons, etc, and html for displaying documents

alandipert20:04:30

that is interesting

micha20:04:52

i guess being able to embed svg in html is something

jumblerg20:04:54

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.

alandipert20:04:56

i am reminded of the bad/good old days of table layout

jumblerg20:04:37

hoplon ui uses tables

jumblerg20:04:46

well, (ab)uses

jumblerg20:04:34

it is also, incidentally, a table-cell

jumblerg20:04:44

that’s how ui centers things vertically, horizontally

jumblerg20:04:10

but there could just as easily be an svg overlay rolled into there for that purpose instead

jumblerg20:04:22

or a set of them for each predefined state of the component

jumblerg20:04:03

why use css for the component stylization at all when svg is an option?

micha20:04:09

how is svg an option though?

jumblerg20:04:47

the “picture” of the component could be implemented in as an svg overlay, background i think.

jumblerg20:04:36

maybe using absolute layout, constrained to the size of the component, one z-index behind

jumblerg20:04:43

or something like that

jumblerg20:04:14

children would still be passed into the inner html div

jumblerg20:04:38

also, this would help make this easier: https://github.com/hoplon/hoplon/pull/122 simple_smile

jumblerg20:04:47

just give me this one, man…. simple_smile

micha20:04:19

haha yeah we might as well merge that

jumblerg20:04:49

excellent. glad i’m wearing you down.

micha20:04:04

i wonder if higher-order macros work in cljs

micha20:04:16

like a macro that defines macros

jumblerg20:04:37

what’s the application?

micha20:04:41

i guess not, it would need to emit cljs

micha20:04:08

well i want to have like

micha20:04:31

(defcontext screen
  *foo*
  *bar*)

micha20:04:40

and that would define two macros:

micha20:04:51

(with-screen ...)

micha21:04:06

(binding-screen ...)

micha21:04:09

or something like that

jumblerg21:04:31

presumably for responsive layouts

micha21:04:37

i suppose it can be done in clj and then it would probably be available in cljs

micha21:04:46

well it's for organizing state

micha21:04:02

not really anything to do with layouts

micha21:04:21

defining contexts that hold some cells

micha21:04:27

so you can better scope them

jumblerg21:04:09

what is the scoping problem you’re trying to solve?

micha21:04:20

i mean the solution there works, but it could be more compact

micha21:04:40

you'd use it the same way, but creating the context could be simpler with some macrologies

jumblerg21:04:06

i’m tracking now, i think.