Fork me on GitHub
#re-frame
<
2016-06-30
>
escherize01:06:13

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

rui.yang08:06:35

wonder if anyone has any issue using reframe with language input in text input. trying put non english in a input box

martinklepsch10:06:44

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?

fasiha14:06:52

@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

richiardiandrea15:06:09

@martinklepsch: it should be right, dynamic should mean only that inside :a you receive a raw reaction, if I understood correctly

mikethompson22:06:10

@martinklepsch: when you say "the same". Do you mean the two would return true for = OR do true for identical?

rui.yang22:06:42

@fasiha thanks for replying. i will try to create sth to demo my issue, i must have done sth wrong.

mikethompson22:06:17

@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.

mikethompson22:06:10

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)

martinklepsch22:06:15

@mikethompson: I actually mean identical? - so for master the answer would be they're not while for develop they would be identical, yes?

martinklepsch22:06:56

Subscription de-duplication is a great improvement! 👍

kingoftheknoll22:06:13

Are there any good writeups about deeply nested (2-4 layers deep) routing using any of the popular routing libs: silk, secretary, bibi?

kingoftheknoll22:06:31

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.

kingoftheknoll22:06:17

Compared to react-router which tightly couples component to route fragment which makes perfect sense.

martinklepsch23:06:18

@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?

martinklepsch23:06:15

@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"

kingoftheknoll23:06:11

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

martinklepsch23:06:13

Is :message a change to the route or a new message?

martinklepsch23:06:07

I usually have a map that represents the current route in my application state and derive the UI from that

danielcompton23:06:04

@martinklepsch: what would it look like to create all subs from a static spec?

danielcompton23:06:38

I think it would be unusual to dynamically create subscriptions in prod, but they can be reloaded by figwheel

martinklepsch23:06:13

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

kingoftheknoll23:06:05

Do you use a single event for a route change?

martinklepsch23:06:48

@kingoftheknoll: yes — or actually two, one to change the route and one to react to a changed route (href etc)

martinklepsch23:06:10

@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)))]})

kingoftheknoll23:06:48

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

martinklepsch23:06:52

@danielcompton: for efficiency (i.e. not creating unused reactions) this needs some sort of registry as well but that's at a different level

danielcompton23:06:26

Subscriptions can be registered, but no reaction is created until they’re used

danielcompton23:06:37

And then they are removed when no-one is depending on them

martinklepsch23:06:42

@kingoftheknoll: with bidi the route data is a plain map so I mostly just give that data to a case etc

martinklepsch23:06:44

@danielcompton: yes, I know, question is: Why register subscriptions instead of "declaring" them.

martinklepsch23:06:04

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

danielcompton23:06:54

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

danielcompton23:06:48

i.e. I’m still not seeing why you’d want to do that

martinklepsch23:06:28

@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

kingoftheknoll23:06:53

@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

danielcompton23:06:03

yeah just code org, and keeping whitespace the same for surrounding subs when you change one

martinklepsch23:06:11

@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

martinklepsch23:06:23

> keeping whitespace the same for surrounding subs I don't understand?

danielcompton23:06:59

(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