This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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
(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...
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.
(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, could you say that
reg-sub creates a "query" by that name, and that you
subscribe to that query?
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
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
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?
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 [:blah 1]) will create a different signal graph to
(subscribe [:blah 2]) <-- important concept
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.
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
@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
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.
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 🙂
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.
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!