Fork me on GitHub

@(rf/subscribe [:something]) works really great in the repl!


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: (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
/b -> give 12 to -> /bb


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?


  (fn [])
  (fn []))
  (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