This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-07
Channels
- # aleph (15)
- # beginners (18)
- # boot (18)
- # business (1)
- # cider (11)
- # cljs-dev (13)
- # cljsrn (19)
- # clojure (14)
- # clojure-austin (8)
- # clojure-dusseldorf (1)
- # clojure-finland (1)
- # clojure-greece (118)
- # clojure-poland (3)
- # clojure-russia (46)
- # clojure-spec (65)
- # clojure-uk (18)
- # clojurebridge (3)
- # clojurescript (16)
- # cloverage (7)
- # core-async (8)
- # cursive (74)
- # datomic (28)
- # editors (3)
- # emacs (3)
- # ethereum (5)
- # hoplon (19)
- # jobs-rus (18)
- # lein-figwheel (1)
- # off-topic (2)
- # om (107)
- # om-next (4)
- # onyx (23)
- # pedestal (23)
- # proton (3)
- # protorepl (1)
- # re-frame (108)
- # reagent (10)
- # ring-swagger (15)
- # spacemacs (2)
- # specter (11)
- # testing (7)
- # untangled (79)
- # vim (4)
- # yada (53)
@mattly thanks, I'll check it out! Re: handler: would you mind sketching a minimal example? Sounds interesting, but I'm not sure I'm following properly
when you (subscribe [:foo])
in your views, how do you call the thing you subscribe to?
> The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. -- Alan Perlis http://www.cs.yale.edu/homes/perlis-alan/quotes.html
this may seem like a pedantic question, but I feel there's a word missing for a key concept...
@plexus not sure of the question. Can you restate?
instead of "/abc/:id/def" bidi asks you to write ["/abc/" :id "/def"]
- nothing to stop you writing some mapping but the reason for the data structure is extensibility. For example, say you wanted the id to be a keyword or uuid (only) to avoid injection attacks perhaps, you can write ["/abc/" [keyword :id] "/def"]
or ["/abc/" [uuid :id] "/def"]
, and so on, recursively.
reg-sub
registers a "subscription handler", under a certain name. When you do subscribe
in a view, you create a subscription (IMO you can't speak of a subscription until something has actually been subscribed to). But as long as there is no subscription (from a view), what do you call :blocks
? "registered subscription handler" seems the most accurate. So (subscribe [:blocks])
subscribes to... the :blocks
subscription handler?
IDK I'm probably being too pedantic, but something like "stream", like you subscribe to the $x stream
, instead of you subscribe to the $x registered subscription handler
or maybe the answer is just "subscription", which seems to be how it's used now, so that reg-sub
creates a subscription, and subscribe
subscribes to that subscription. Just sounds funny to me.
Hmm. (subscribe [:blocks])
creates a subscription. A subscription is a reactive query (computation) over app-db
. There is a handler which performs the computation
and which is registered for the query-id
.
Not sure I'm helping
if it's query-id
, could you say that reg-sub
creates a "query" by that name, and that you subscribe
to that query?
Hmm. You are making me think here :-)
reg-sub
associates a query-id
with a handler fn.
Later, when a subscribe happens, a signal graph (of some complexity) is instantiated.
yeah, it doesn't "create" so much as it "registers" a thing under a name... I just feel like there's a word missing to point at that as a concept
The subscribe
is what creates things
a flow
a signal graph
involving computations
you can't say subscriptions, those don't exist until you subscribe
. "subscription handlers" would be accurate but wordy. "queries" is conceptually I think closest to what I'm looking for
reg-sub
is like defn
in nature
Indeed
And calling that function, may itself cause other functions to be called
I mean it's not super vital, I'll be fine 🙂 but can you see how I'm grappling for a name for this concept?
Yeah, i do understand
I'm just writing stuff down, waiting for that moment of clarity
So a signal graph is a runtime concept, like a function call.
Only the nature of a signal graph is to hang around, reactively delivering a stream of values over time. At runtime.
A signal graph is instantiated via subscribe
Note that (subscribe [:blah 1])
will create a different signal graph to (subscribe [:blah 2])
<-- important concept
So, reg-sub
is about defining a function which can compute a node
in a signal graph. In the same way that defn
defines the fucnction that gets called.
is it possible to call .focus
on a re-com/input-text
?
I don't see a way to get a ref to the input DOM node
@pesterhazy can you just set the style auto-focus
That will initially set focus
To a newly instantiated input-field (I seem to remember)
I hope I'm remembering correctly
I can indeed
:attr {:auto-focus true}
thanks @mikethompson !
the wonders of HTML5
Mmmm. The HTML5 Drag and drop API
Tasty
@mikethompson I'm playing around with re-com, it's very nice
is there a way to clear a typeahead
control?
I'm not sure, it was generously donated. i didn't design, so I haven't had a chance to look into to it much
didn't realize it was so new
I can't seem to change the value by changing the model
that does work for input-text
though right?
@pesterhazy should do
is there a reason to pass an atom rather than the deref'd as a model?
or is that just a convenience?
convenience
BTW, the layout side of re-com is the part I'm proudest of.
vbox and hbox etc. Given what a nightmare layout normally is
But everyone always focuses on the widgets :-)
@plexus Over time, I've found it difficult to describe the subscriptions side of things top down - ie. concepts first, then mechanics. I notice that I've always ended up going the other way - mechanics first, leading to concepts. You'll note the README starts off with a discussion of ratoms
and reactions
(ie mechanism) and then works "upwards" from there towards signal graphs.
Now, of course, I can get a bunch of concepts and definitions together, but its always seemed to me that they would just confuse people if they were presented first.
But that kinda annoys me. Would love to find a way to go more top down.
@mikethompson I like the layout too but takes a while to get used to it
I'm not crazy about the [comp :k1 :v1 :k2 :v2]
structure
named parameters?
I think regular reagent style [comp {:k1 :k2} :child1 :child2]
is clearer
yes, especially for children
I guess using only named k/v style props is more consistent though
We spent a long time agonizing over those decisions. Can't remember all the ins and outs off hand. But it becomes very natural very quickly.
A question about performance, we are in love with interceptors and use them for persistence, specking app-db and logging in react native. The problem is that since they run without interruption it gets quite laggy. Any tips on the best way I can postpone my side-effecting interceptors and let React Native re-render before it processes them?
@vikeri not an expert, but can you just dispatch an event to perform side effects? This way side effects will be deferred
uhm, strange, can't find almost nothing interesting in Google about breadcrumbs in CLJS webapps
I'm doing a Lambda Island episode on re-frame (a first of several probably). The example code I'll be using is here https://github.com/lambdaisland/breakout
I'll start recording tomorrow, so if anyone feels like telling me I'm doing it all wrong now's the time 🙂
or you can just play around with the demo https://lambdaisland.github.io/breakout/
I think you forgot the ball 🙂
I'll try and look through it a bit and see if anything jumps out at me - not saying I know what I'm doing either though 🙂
I did actually have a working version of the game, but it was a bit hacky. I discovered http://thi.ng/geom too late
mine are a bit of a mixed bag at the moment, some closer to the UI domain, some closer to the game domain, e.g. block-clicked vs create-block
also past tense vs present tense... in event sourcing/cqrs they tend to write them in the past tense
I prefer a name closer to the domain, at least for what I've been working on latey. I found that if I named it "something-clicked" I ended up wanting it also run in another way (eg from clicking or a keyboard shortcut) and was having to rename things a bunch.
Refactoring is still very much replace all for some things too, but it's not too bad.
OTOH something you want a click on a thing to do different things depending on the current state of things. Maybe it makes sense to have two "layers", UI events that dispatch to domain events, so multiple UI events can trigger the same domain events, or a single domain event can dispatch to different domain events
Yeah. I've also found that namespacing my events has helped quite a bit for that type of split
@mikethompson: fwiw, I've found the re-com layout containers very handy so far! They remind me of (please take this as a compliment) Adobe Flex, which had quite a good panel-based layout story.
@amacdougall I loved Flash/Flex. Loved it. Sooooo very far ahead of the HTML5 game. I was really annoyed when I realised it was going to die. The only good thing to come out of it was being forced across into ClojureScript.
Well, that explains the similarities! And yeah, it really let you do a lot... too bad it was based on Flash. Flex was fine, but its runtime was doomed.
How good would it be to have Reagent on top of MXML (instead of HTML5)?
Seriously. Right now I'm largely protected from the details of HTML (the benefits of being in a larger company), but whenever I have to dip into it, it's... well, a lot better than it was!
2001-era HTML/CSS/JS drove me into Java and then back to the front end by way of AS3. Only recently has JS become bearable, at the cost of a Cambrian explosion of tools.