This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-30
Channels
- # admin-announcements (3)
- # aws-lambda (12)
- # beginners (88)
- # boot (73)
- # capetown (6)
- # carry (16)
- # cider (8)
- # cljsjs (7)
- # clojure (90)
- # clojure-belgium (4)
- # clojure-dev (19)
- # clojure-greece (41)
- # clojure-portugal (1)
- # clojure-quebec (4)
- # clojure-russia (25)
- # clojure-spec (172)
- # clojure-taiwan (1)
- # clojure-uk (76)
- # clojurescript (82)
- # cursive (37)
- # datavis (2)
- # datomic (46)
- # devcards (1)
- # emacs (4)
- # euroclojure (6)
- # events (1)
- # hoplon (31)
- # jobs (1)
- # keechma (9)
- # off-topic (4)
- # om (7)
- # onyx (65)
- # other-languages (15)
- # pedestal (1)
- # planck (50)
- # proton (1)
- # re-frame (40)
- # reagent (7)
- # spacemacs (14)
- # spirituality-ethics (37)
- # testing (1)
- # untangled (2)
- # yada (44)
wonder if anyone has any issue using reframe with language input in text input. trying put non english in a input box
with dynamic subs, when subscription :a
depends on :b
and I also use :b
in a component are the two :b
reactions (one in sub, one in component) the same?
@rui.yang: nope, I work with Japanese all the time and language/text-encoding-related issues at least is one thing that hasn't bitten me
@martinklepsch: it should be right, dynamic should mean only that inside :a you receive a raw reaction, if I understood correctly
@martinklepsch: when you say "the same". Do you mean the two would return true
for =
OR do true for identical?
@fasiha thanks for replying. i will try to create sth to demo my issue, i must have done sth wrong.
@martinklepsch: I'm assuming you mean =
... in which case the answer is "eventually". There could be a "glitch" in which one reactive computation is done before another. So one :b
could be recomputed (from its inputs) before another.
BTW: with the upcoming v0.8.0 subscriptions are deduplicated. Some preparatory information at the top of this WIP document: https://github.com/Day8/re-frame/blob/develop/CHANGES.md (in the develop branch)
@mikethompson: I actually mean identical?
- so for master the answer would be they're not while for develop they would be identical, yes?
Subscription de-duplication is a great improvement! 👍
Are there any good writeups about deeply nested (2-4 layers deep) routing using any of the popular routing libs: silk, secretary, bibi?
I’m having a hard time wrapping my head around the concept of a dispatch event for a leaf node in a routes tree causing all of it’s parent components to render. <- if that makes any sense at all.
Compared to react-router which tightly couples component to route fragment which makes perfect sense.
@mikethompson: wondering: where do you see the benefits of "registering" subscriptions vs. creating all needed subs from a static specification? Are there reasons why the set of subscriptions should be runtime-extensible?
@kingoftheknoll: generally components update when their arguments or a deref'd ratom change. I'm not sure I fully understand what you mean by "dispatch event for a leaf node"
Hey @martinklepsch for instance /#/inbox/message/1231
the router matches a nested state so I dispatch an event for :message but how would the handler for inbox know to render
Is :message a change to the route or a new message?
I usually have a map that represents the current route in my application state and derive the UI from that
@martinklepsch: what would it look like to create all subs from a static spec?
I think it would be unusual to dynamically create subscriptions in prod, but they can be reloaded by figwheel
Eg a :location/change event leads to an updated :route key in my app state and my main component uses a subscription returning the route, so whenever the route changes the views are updated as well
Do you use a single event for a route change?
@kingoftheknoll: yes — or actually two, one to change the route and one to react to a changed route (href etc)
@danielcompton: I've been experimenting with something that works with a structure like this as basis:
(defn reactive-spec [base]
{:base [[] base]
:inc [[:base] (fn [base] (inc base))]
:as-map [[:base :inc] (fn [base inc] {:base base :after-inc inc})]
:sum [[:as-map] (fn [as-map] (+ (:base as-map) (:after-inc as-map)))]})
That makes sense. Do you then transform the emitted value from the router to something that components subscribe to or are you just letting components inspect the route data
@danielcompton: for efficiency (i.e. not creating unused reactions) this needs some sort of registry as well but that's at a different level
Subscriptions can be registered, but no reaction is created until they’re used
And then they are removed when no-one is depending on them
@kingoftheknoll: with bidi the route data is a plain map so I mostly just give that data to a case
etc
@danielcompton: yes, I know, question is: Why register subscriptions instead of "declaring" them.
I guess the "declaring" might be confusing terminology, what it comes down to is: register-sub
vs register-subs
that is one-by-one vs. all-in-one-go
We have subs spread across many files in large apps. There’s no particular reason why you couldn’t write register-subs
yourself. Not totally sure what it would buy you, but I don’t see any issues
i.e. I’m still not seeing why you’d want to do that
@danielcompton: right, code org makes sense. I'm not saying there should be a register-subs
rather just wanted to understand the reasoning behind choosing one or the other
@martinklepsch: Thanks! I’m going to jump into the repl and play with bidi a bit. One last question if you don’t mind. When you match a case
do you then pass the remaining route information to child components so they can make their own rendering decisions? Such as:
route = /b/bb/12
/a
/b -> give 12 to -> /bb
/c
yeah just code org, and keeping whitespace the same for surrounding subs when you change one
@danielcompton: I think in a re-frame context it doesn't make much sense to have register-subs
but I've been hacking on a subscription/materialized view system today which doesn't have any globals on it's own so there are different constraints
> keeping whitespace the same for surrounding subs I don't understand?
(register-subs
:sub1
(fn [])
:sub2
(fn []))
(register-subs
:sub1
(fn []))
you will get whitespace changes on :sub1 when you delete :sub2 even though it didn’t change. It’s a pretty minor thing though