This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (165)
- # boot (9)
- # cider (9)
- # cljs-dev (5)
- # cljsjs (5)
- # clojars (4)
- # clojure (207)
- # clojure-brasil (1)
- # clojure-greece (3)
- # clojure-poland (2)
- # clojure-russia (6)
- # clojure-spec (85)
- # clojure-taiwan (1)
- # clojure-uk (53)
- # clojurescript (96)
- # community-development (2)
- # cursive (4)
- # datomic (14)
- # emacs (41)
- # events (2)
- # hoplon (184)
- # leiningen (1)
- # nginx (1)
- # off-topic (16)
- # om (7)
- # onyx (63)
- # pedestal (27)
- # planck (17)
- # protorepl (3)
- # rdf (9)
- # re-frame (62)
- # reagent (7)
- # ring-swagger (5)
- # schema (2)
- # spacemacs (5)
- # test-check (25)
- # untangled (93)
- # yada (3)
@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?
@onetom: i think .abort is a method of the ajax object; it shouldn't change anything in that regard.
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
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.
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.
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.
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.
there's a practical benefit as well though; i don't think the jquery and es6 promise chains play nicely together.
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.
i'll provide some later tonight. you can google mozilla's getUserMedia, webrtc, websockets docs to see how the browser exposes ES6 promises now.
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.
i saw your
*state* stuff but i was not sure where were you going with it, so i just made a monolithic solution
@micha is there a canonical place for form-machine yet or it's not been factored out from your app yet?
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
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.
the problem w the preventDefault approach is that mobile clients which use their built-in, native form widgets will not work probably
it may be that certain functions need to be lifted out to be the user as micha suggested.
the issues may be also similar to those he is encountering factoring out the form machine approach.
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.
it's just that if you wanted to do a different thing you'd make a new machine rather than configure this one
@micha makes sense to me ^^ i just spent some time moving my form errors somewhere that other parts of the system could reference
although my implementation isn’t as generalised as yours >.<
i needed to add tabbed navigation to a form and not allow access to a particular tab if there were errors in the form
also, i’m using websockets with hoplon just fine atm by leveraging sente + cells
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.
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.
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.
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.
personally i’m currently only using jquery directly because i find it easier to write tests
the fact that hoplon uses it under the hood isn’t impacting me
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 %)))
.getUserMediais a native async function returning a
MediaStreamthrough a promise,
connect-to-peerwraps the native
RTCPeerConnectionwhich also returns an ES6 promise, and
initiate-peer-sessionis a castra command.
@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.
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.
yeah i’m agreeing with you
i’m saying that i don’t see jquery being used as a positive or negative
so if it’s causing problems, no skin off my back 🙂
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.
that’s pretty cool
the only concern i have, which might be totally unfounded because i haven’t played with the new stuff that much
is that there seem to be quite a few new different ways to tackle async stuff coming out
although promises seem like they’re probably here to stay
we've discussed the core.async stuff quite a bit and decided not to use it; are there others?
a lot of stuff in browsers does get played with for a bit then deprecated
i mean in js itself
like i said, i haven’t played with it much yet, just hearing about them but like async/await, observables, service workers, etc.
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.
yeah, promises are likely to stick around i think
some of the other stuff i can see getting half implemented by browsers, not really taking off then being ripped out again later
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.
i don’t get a strong sense of vision/cohesion from new js shiny
i feel like they’re just chucking shit in from other languages and popular libs/frameworks
and then seeing what wins the popularity contest
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.
oh that’s cool
i haven’t seen that before
yeah it could be
they’re specifically talking about C/C++ but i imagine you could compile other things to it as well?
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
i can't reproduce the issue in my isolated example (`tst/hoplon/forms.cljs`) yet; that works 😕
@onetom: on the latest push i did away with
html entirely; you can now add hoplon children anywhere (although this is not advisable).
if you set the padding, gutters, or layout on a parent, they will not work on children that are not
@jumblerg so i haven’t actually used hoplon ui yet
is it like a library of components?
@thedavidmeister: not exactly; it utilizes hoplon's foundation to create a small set of more powerful primitives that can be used to build components.
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.
mmk, so the aim is to use less css?
ok, how far along are you in that?
ok, so it’s more than just layout stuff?
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.
it should give you a way of doing everything you could do with css before, but much better. 🙂
do they look like this: http://cdn.dezzain.com/1/2013/03/no-css-html.png? (joking, of course)
the project page says EXPERIMENTAL, yada yada
so i wasn’t really sure
i'll remove the experimental label when we have a complete solution for forms, layers, etc.
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.
i literally just moved from sass to garden
i don’t think i’m emotionally ready to make the jump to something else yet
@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.
@thedavidmeister: lol. it is a journey. i have full confidence you'll get there.
@jumblerg the whole hoplon journey seems to be a new refactor every month
in a good way
it’s really just me learning better ways to approach problems
haha js is changing their shit every day regardless of me
hoplon seems like it hasn’t changed much, but i’m just getting better ideas of how to leverage it
i was doing some hacking where i was using a photoshop-style resize tool to layout elements using this model.
you going to make a webflow competitor?
@thedavidmeister: some sample code is here: https://github.com/hoplon/ui/blob/master/tst/hoplon/demo.cljs
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?"
actually not sure because i haven’t used it for anything serious
just commissioned other ppl to 😛
but my understanding is that it’s more like a UI for CSS rules directly
yeah, i don't touch these products either. but i occasionally watch other people try to use them. this amuses me.
so you get a photoshop style set of buttons that are actually just css rules
you have to know css if you want to use it
huh. yeah, anything that builds code for you based on css will become completely unmanageable pretty quickly.
it’s more supposed to be for ppl who know html and css, but they want to use buttons instead of typing
random q, if i do
(j/cell= (assert foo)) will that get removed by the advanced compiler?
@thedavidmeister i doubt it, but if need interested to know
just something i thought of while playing around
yeah, i was wondering if setting that option would also remove the cell
or just the inner assert
and the last radio group could be defined as:
using this little custom component:
(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"))
(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)))
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"))
@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...
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