Fork me on GitHub
#hoplon
<
2016-11-21
>
onetom01:11:27

@jumblerg im using the .abort on jQ.xhr promises in case of autocompletion. how would i do that with the polyfill u mentioned? i should still make a custom promise which carries the xhr object along somehow, no?

jumblerg01:11:24

@onetom: i think .abort is a method of the ajax object; it shouldn't change anything in that regard.

onetom01:11:11

yes, but currently it's passed down along w the promise so at the user level u have the chance to interact w the xhr object

jumblerg01:11:53

that shouldn't change

onetom01:11:25

maybe it should return both the xhr an the promise independently?

jumblerg01:11:08

as i recall, the current implementation actually returns its own promise that proxies the one from xhr. this proposed change would take the same approach.

micha01:11:49

how is the current implementation incompatible with websockets?

jumblerg01:11:00

i agree with mynomoto philosophically, as i've said several times upstream.

jumblerg01:11:25

we should have only one supported way of doing things.

jumblerg01:11:03

it is not incompatible.

jumblerg01:11:56

we have promises that are used frequently in many of the browsers apis now. sockets are one. getUserMedia is another. a third is the webrtc/ortc api.

jumblerg01:11:16

there will be more. i think the jQuery promise served its purpose in its time, but now that promises are part of ES6, in keeping with the one way philosophy, we should adapt.

micha01:11:40

i don't know

micha01:11:50

chasing the latest shiny

micha01:11:12

i don't know if we want to break compatibility for that

micha01:11:46

it's good that it's a standard

micha01:11:08

but if it aint broke, we might not want to fix it

jumblerg01:11:35

that's really the question, is it worth breaking backwards compatibility for?

jumblerg01:11:50

i think it may be because ES6 promises are permanent and here to stay; we might as well fall in line with the standard. and the impact is low.

jumblerg01:11:06

there's a practical benefit as well though; i don't think the jquery and es6 promise chains play nicely together.

micha01:11:14

it's easy to adapt it yourself though

micha01:11:29

without changing castra

jumblerg01:11:49

agreed, it is not a big deal.

jumblerg01:11:40

user code simply becomes cleaner once we embrace es6 promises instead.

jumblerg01:11:24

i can share some practical examples once i'm behind my laptop.

jumblerg01:11:29

we could probably also make the change in a non-breaking way.

jumblerg01:11:11

by appending / proxying the jq promise interface to the native one.

jumblerg01:11:00

(and maybe add a depreciation notice)

jumblerg01:11:46

to the extent that our environment changes around us, the host platform changes below us, at some point we become more future compatible by adapting. much like we did by adapting transit in castra.

onetom01:11:03

i would be happy to see the examples too

jumblerg02:11:10

i'll provide some later tonight. you can google mozilla's getUserMedia, webrtc, websockets docs to see how the browser exposes ES6 promises now.

onetom02:11:23

@jumblerg btw, did you have a chance to look into my hoplon/ui form extensions?

onetom02:11:41

i've added single and multiple select support too

jumblerg02:11:06

more generally, i think we're reaching a point where the need for jquery has nearly run its course, and hoplon/castra becomes simpler by eliminating this dependency.

jumblerg02:11:02

@onetom: not yet, but i will. thanks for putting that together.

onetom02:11:35

i saw your item* and interactive and *state* stuff but i was not sure where were you going with it, so i just made a monolithic solution

onetom02:11:29

@micha is there a canonical place for form-machine yet or it's not been factored out from your app yet?

micha02:11:24

i haev not been able to successfully factor it out yet

micha02:11:29

other than in gists

onetom02:11:03

i just realized last week that the main issue with web forms and reactive frameworks is that you can't just sync your form-data model into the dom state in one direction; you have to pick up changes in the dom state or prevent default browser behaviour and simulate it by changing the model

jumblerg02:11:26

while i think we have the general api right, i keep running into obstacles with the form implementation that have to do with the underlying abstractions we're using.

onetom02:11:08

the problem w the preventDefault approach is that mobile clients which use their built-in, native form widgets will not work probably

jumblerg02:11:34

it may be that certain functions need to be lifted out to be the user as micha suggested.

jumblerg02:11:43

the issues may be also similar to those he is encountering factoring out the form machine approach.

micha02:11:01

it's more of a pattern than a library

jumblerg02:11:18

@micha: we should coordinate on this sometime... yeah.

jumblerg02:11:47

and that's what you end up with by lifting out the things that don't generalize well to the user. but to the extent a pattern in one's code is indicative of an error in notation (perlis), i think there's a key abstraction we're missing here.

micha02:11:21

it's not a pattern

micha02:11:26

in that way

jumblerg02:11:29

not that all repetition is bad, esp at the top level of abstraction.

micha02:11:36

there is no repetition

micha02:11:06

it's just that if you wanted to do a different thing you'd make a new machine rather than configure this one

micha02:11:07

making false abstractions doesn't help

micha02:11:26

trading code for config maps and whatnot

micha02:11:29

that code is the core of our application in a lot of ways

micha03:11:27

i looked around for a useful state machine formulation

micha03:11:43

and there doesn't appear to be one that is as good as just doing it the naive way

micha03:11:39

the main idea there is that you have an object that keeps its state in javelin cells

micha03:11:00

and has methods that request a transition

micha03:11:42

other pieces of program can make formulas over the cells in the machine

micha03:11:12

so it fits right in with the rest of hoplon naturally

thedavidmeister06:11:54

@micha makes sense to me ^^ i just spent some time moving my form errors somewhere that other parts of the system could reference

thedavidmeister06:11:05

although my implementation isn’t as generalised as yours >.<

thedavidmeister06:11:51

i needed to add tabbed navigation to a form and not allow access to a particular tab if there were errors in the form

thedavidmeister06:11:29

also, i’m using websockets with hoplon just fine atm by leveraging sente + cells

jumblerg07:11:10

back on the subject of castra and promises, now that i'm behind my laptop: the benefit of using promises, over generic callbacks, is that they enable the programmer to chain a series of asynchronous calls in a linear fashion.

jumblerg07:11:53

this is realized when there are multiple asynchronous operations that need to be executed in serial fashion, but in order for these operations to be chained to describe a computation in linear fashion, they must all implement a common interface.

jumblerg07:11:14

in other words, for them to be of any value in the first place, they need to play nicely with others; they add an unnecessary layer of indirection with no benefit otherwise.

jumblerg07:11:40

by using jQuery promises, which implement a different interface from ES6 promises, in an environment where ES6 promises are now the standard, we introduce another type of thing that doesn't need to be there, and thereby make the process of composition more difficult. we can't compose ES6 promises and jQuery promises into the same chain.

thedavidmeister07:11:30

personally i’m currently only using jquery directly because i find it easier to write tests

thedavidmeister07:11:41

the fact that hoplon uses it under the hood isn’t impacting me

jumblerg07:11:42

the practical benefit of implementing these native promises, in castra, is that it allows us to do the following:

(-> (.getUserMedia (.-mediaDevices js/navigator))
    (.then #(connect-to-peer % p/servers))
    (.then initiate-peer-session))
    (.catch #(reset! error %)))
where .getUserMedia is a native async function returning a MediaStream through a promise, connect-to-peer wraps the native RTCPeerConnection which also returns an ES6 promise, and initiate-peer-session is a castra command.

jumblerg07:11:14

@thedavidmeister: i'm focused a bit more narrowly, in this specific case, on only one aspect of jQuery, the fact that jQuery promises can't be chained with ES6 promises without adaptation.

jumblerg07:11:49

while this is a bit of a different conversation, i don't think there's much benefit to utilizing jQuery anymore; it has been largely factored out of hoplon already with the exception of the attribute providers and a few utility functions, and since these aren't used in hoplon/ui, my apps don't use it.

thedavidmeister07:11:04

yeah i’m agreeing with you

thedavidmeister07:11:31

i’m saying that i don’t see jquery being used as a positive or negative

jumblerg07:11:38

(thanks for all the work on the tests, btw - super helpful)

thedavidmeister07:11:44

so if it’s causing problems, no skin off my back 🙂

jumblerg07:11:38

where it jQuery still gets pulled in, in my apps, is castra. it is used for both the promises and xhr requests; we should use native promises for the former now, imho - and for the requests themselves, we could probably factor it out quite easily with no loss at this point.

thedavidmeister07:11:43

that’s pretty cool

jumblerg07:11:02

hoplon is jquery for clojurescript devs, basically, at this point.

thedavidmeister07:11:23

the only concern i have, which might be totally unfounded because i haven’t played with the new stuff that much

thedavidmeister07:11:39

is that there seem to be quite a few new different ways to tackle async stuff coming out

thedavidmeister07:11:54

although promises seem like they’re probably here to stay

jumblerg07:11:27

we've discussed the core.async stuff quite a bit and decided not to use it; are there others?

thedavidmeister07:11:31

a lot of stuff in browsers does get played with for a bit then deprecated

thedavidmeister07:11:39

i mean in js itself

thedavidmeister07:11:25

like i said, i haven’t played with it much yet, just hearing about them but like async/await, observables, service workers, etc.

jumblerg07:11:37

hm, i actually don't follow that stuff to closely; the reason i think we need to move to the ES6 promises is because those are here to stay and part of the brower's core apis at this point.

thedavidmeister07:11:54

yeah, promises are likely to stick around i think

thedavidmeister07:11:19

some of the other stuff i can see getting half implemented by browsers, not really taking off then being ripped out again later

jumblerg07:11:34

(like .getUserMedia in the example above)

jumblerg07:11:51

yeah, totally.

jumblerg07:11:56

typically the new shiny things aren't really that new semantically upon more thoughtful examination (e.g. worker threads, cors vs iframes), and they tend to lose their luster rather quickly when they get deprecated shortly after being added in.

thedavidmeister07:11:38

i don’t get a strong sense of vision/cohesion from new js shiny

thedavidmeister07:11:50

i feel like they’re just chucking shit in from other languages and popular libs/frameworks

thedavidmeister07:11:02

and then seeing what wins the popularity contest

jumblerg07:11:46

yeah. not a fan of the new OOP syntactic sugar they're mixing in, for example. i was just reading that WebAssembly is hitting Chrome Canary though; maybe we'll be able to ignore all of this pretty soon.

thedavidmeister07:11:49

oh that’s cool

thedavidmeister07:11:55

i haven’t seen that before

jumblerg07:11:28

that's going to be huge, i think.

thedavidmeister07:11:06

yeah it could be

thedavidmeister07:11:31

they’re specifically talking about C/C++ but i imagine you could compile other things to it as well?

onetom09:11:58

@jumblerg is hoplon.ui/html the escape hatch? i don't quite understand how can that work 😕 and i just started to have problems with it when i put h/option dom elems into a select hui/Elem

onetom09:11:29

i can't reproduce the issue in my isolated example (`tst/hoplon/forms.cljs`) yet; that works 😕

jumblerg09:11:31

@onetom: on the latest push i did away with html entirely; you can now add hoplon children anywhere (although this is not advisable).

jumblerg09:11:34

i've been making things less rigid so refactoring will be easier.

jumblerg09:11:21

if you set the padding, gutters, or layout on a parent, they will not work on children that are not Elems.

onetom09:11:17

awesome, thanks! i will pull right away

thedavidmeister10:11:07

@jumblerg so i haven’t actually used hoplon ui yet

thedavidmeister10:11:12

is it like a library of components?

jumblerg10:11:26

@thedavidmeister: not exactly; it utilizes hoplon's foundation to create a small set of more powerful primitives that can be used to build components.

jumblerg10:11:27

while hoplon's element constructors maintain 1:1 parity with the dom and require the use of css in some form, ui abstracts all of this away entirely.

thedavidmeister10:11:52

mmk, so the aim is to use less css?

jumblerg10:11:05

the aim is to use zero css.

thedavidmeister10:11:54

ok, how far along are you in that?

jumblerg10:11:57

bury that nonsense so deep it is back in hell where it belongs. 🙂

jumblerg10:11:42

i haven't used actual css to build my user interfaces in a few years.

thedavidmeister10:11:48

ok, so it’s more than just layout stuff?

jumblerg10:11:38

there are still corner cases where things don't always work out quite as well as they should, but even then it is probably still easier than wrangling css.

jumblerg10:11:03

it should give you a way of doing everything you could do with css before, but much better. 🙂

dm310:11:24

do they look like this: http://cdn.dezzain.com/1/2013/03/no-css-html.png? (joking, of course)

thedavidmeister10:11:48

the project page says EXPERIMENTAL, yada yada

thedavidmeister10:11:51

so i wasn’t really sure

jumblerg10:11:58

yeah, it is like gmail back in the day.

jumblerg10:11:16

beta for years.

jumblerg10:11:30

gotta manage expectations.

dm310:11:12

seriously, I can't wait to have something to try it out on

jumblerg10:11:20

@dm3: yeah, kinda like that lol

jumblerg10:11:47

i'll remove the experimental label when we have a complete solution for forms, layers, etc.

jumblerg10:11:40

i tried to enumerate the remaining, ugly corners you'll encounter when i pushed the first snapshot to clojars; should be upstream in this little box somewhere.

thedavidmeister10:11:43

i literally just moved from sass to garden

thedavidmeister10:11:54

i don’t think i’m emotionally ready to make the jump to something else yet

jumblerg10:11:07

@dm3: i do think we're on to something, and i'm much more optimistic about its prospects than i was when i started. in the beginning, i wasn't sure if the abstractions were sufficiently generalizable for it to work.

dm310:11:32

they must be 🙂 desktop software doesn't have CSS 🙂

jumblerg10:11:51

@thedavidmeister: lol. it is a journey. i have full confidence you'll get there.

dm310:11:05

or I guess it has now, when you can make desktop apps on top of the browser

thedavidmeister10:11:38

@jumblerg the whole hoplon journey seems to be a new refactor every month

thedavidmeister10:11:53

it’s really just me learning better ways to approach problems

dm310:11:03

hehe, have you seen the javascript ecosystem?

thedavidmeister10:11:35

haha js is changing their shit every day regardless of me

thedavidmeister10:11:47

hoplon seems like it hasn’t changed much, but i’m just getting better ideas of how to leverage it

dm310:11:51

at least you're using the same build tool

jumblerg10:11:53

i was doing some hacking where i was using a photoshop-style resize tool to layout elements using this model.

jumblerg10:11:51

it holds up quite well.

thedavidmeister10:11:04

you going to make a webflow competitor?

jumblerg10:11:02

does webflow have the usual escape hatch most of these products have, where they tell you to "use our tool to build your website, but when it gets too complicated, insert your own htm and css that will break all our generated stuff here?"

thedavidmeister10:11:45

actually not sure because i haven’t used it for anything serious

thedavidmeister10:11:51

just commissioned other ppl to 😛

thedavidmeister10:11:05

but my understanding is that it’s more like a UI for CSS rules directly

jumblerg10:11:21

yeah, i don't touch these products either. but i occasionally watch other people try to use them. this amuses me.

thedavidmeister10:11:25

so you get a photoshop style set of buttons that are actually just css rules

thedavidmeister10:11:46

you have to know css if you want to use it

jumblerg10:11:56

huh. yeah, anything that builds code for you based on css will become completely unmanageable pretty quickly.

thedavidmeister10:11:20

it’s more supposed to be for ppl who know html and css, but they want to use buttons instead of typing

jumblerg10:11:46

ok. i must go now. before other ppl start showing up at my gym.

thedavidmeister11:11:04

random q, if i do (j/cell= (assert foo)) will that get removed by the advanced compiler?

micha13:11:23

@thedavidmeister i doubt it, but if need interested to know

micha13:11:50

i mean I'd be interested to know

thedavidmeister13:11:00

just something i thought of while playing around

micha13:11:48

there is a way to turn off assertions in production

jumblerg13:11:19

:compiler-options {:elide-asserts true}

jumblerg13:11:34

i do this for production ui builds.

thedavidmeister13:11:50

yeah, i was wondering if setting that option would also remove the cell

thedavidmeister13:11:00

or just the inner assert

jumblerg13:11:21

it appears that it removes the inner assert only

onetom16:11:15

and the last radio group could be defined as:

(row :p (* 2 p) :g g :b 1 :bc transparent-grey
           (radio :marital :status :single "Single")
           (radio :marital :status :married "Married")
           (radio :marital :status :divorced "Divorced")
           (radio :marital :status :widowed "Widowed"))
using this little custom component:
(defn radio [ns key val label]
  (let [k (keyword ns key)
        v (keyword (str (name ns) "." (name key)) val)]
    (hui/label+ :sh (r 1 1) :p p :gh g :av :mid
                :c (c 128 128 128 0.1)
                (hui/radio+ :s 14 :key k :val v)
                label)))

onetom16:11:43

and that little craziness around "Pine apple" looks like this:

(row :p (* 2 p) :g g :b 1 :bc transparent-grey
           (radio+ :key :tree/type :val :tree.type/cat "Apple")
           (radio+ :key :tree/type :val :tree.type/dog
                   (elem :f (em 2) "Pine " (h/i "apple")))
           (radio+ :key :tree/type :val :tree.type/bat "Durian"))

onetom16:11:09

@jumblerg @thedavidmeister we used webflow for a few pages. it's better than squarespace, but at the end u have to know CSS if u want to customise templates and usually u do want to do it, just to be different at least...

onetom16:11:49

iirc webflow has tabular data editor for providing data for loops

onetom16:11:25

i would say if you are doing content authoring, HTML+CSS might still be a reasonable way to go, since you won't need to depend on complicated build systems http://www.csszengarden.com is a good example why you might want to do this

onetom16:11:21

but for webapps i have to say im quite happy with hoplon ui if i don't consider the missing parts