This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-14
Channels
- # aleph (10)
- # announcements (2)
- # beginners (228)
- # calva (18)
- # cider (6)
- # clara (5)
- # cljdoc (25)
- # cljs-dev (22)
- # clojure (78)
- # clojure-dev (30)
- # clojure-europe (2)
- # clojure-finland (1)
- # clojure-italy (32)
- # clojure-nl (21)
- # clojure-uk (126)
- # clojurescript (34)
- # cursive (5)
- # data-science (2)
- # datascript (2)
- # datomic (26)
- # defnpodcast (1)
- # emacs (5)
- # figwheel (5)
- # figwheel-main (3)
- # fulcro (14)
- # graphql (5)
- # jobs (1)
- # keechma (4)
- # nrepl (5)
- # off-topic (35)
- # onyx (3)
- # pedestal (12)
- # random (1)
- # re-frame (35)
- # reagent (8)
- # reitit (20)
- # remote-jobs (5)
- # ring-swagger (20)
- # shadow-cljs (166)
- # sql (43)
- # vim (6)
- # yada (15)
@deg ok thanks anyway. I'll try to contact the contributor. I'll let you know if I find something useful ;-)
@gabrielsimoes sorry to bother you, since you are the contributor of the firestore part in re-frame-firebase, have you tried something like this https://clojurians.slack.com/archives/C073DKH9P/p1542143767323400 Thanks 😉
Hi. I've been using re-frame for awhile. Overall I've been rather happy with it, but now that my application is growing, I've become a bit disenfranchised with the subscription aspect of it. To me, it see like it would be simpler to implement "events" and "effects" as multimethods, and then just have the view be one pure function that takes the app-state and passes it (and subsets of it) to reagent components. Am I missing something that subscriptions are meant to solve?
You get various advantages from subscriptions:
1. a signal graph with propagation pruning (efficiency)
2. shared calculations (nodes) because there is a graph (efficiency again)
3. you can reoganise the structure in your app-db
without changing your views because subscriptions mediate access.
Also, I am personally not that keen on multi-methods. I get that they appear to be convenient but they come with costs. I'm normally very big on convenience, but multi-methods are a tradeoff I didn't want to make.
For example, if effects where done by multi-methods, how could you "stub out" an effect in a test?
Thank you for the thoughtful response. I will have to research signal graphs a bit, as I'm not familiar with the concept. Personally I'm not fond of #3. I don't like the idea of data being represented differently in different parts of the system. What exactly is the issue with multimethods?
@vheuken regarding #3 what happens if a list needs to be sorted in one way in view X but should summarised in view Y. Same data. Different materialized view of it used in two places. That's what subscriptions give you.
We tend to write more complex apps. So we run into these kinds of things
But I get this is not so much an issue with simplier apps
I don't understand your comment about :default
Sorry, gotta head out now.
I can see that use case, but I guess I'm not really sold on why that's more effective than a pure function where the app-state (or subset) is passed in and the "summarised" data returned. Though, like I said, I don't understand the performance implications.
Qucikly: in your proposal about passing app-db
, you will rerender the entire app each time app-db
changes? How will you know what part of app-db
has changed? Effecting which parts of the DOM?
Now, I really do have to go
I think I might be under the impression that Reagent/React are smarter than they actually are.
Hey people! I ran into an issue today with this view not re-rendering. I wanted to make sure if this is the best way to structure a view that is dependent upon parameterized subscriptions.
layout/column and layout/row are just wrappers over recom/v-box and h-box
@lucio no, be careful
That's outside the render function
@uayyagari I'm guessing that arg1
changes over time?
In which case you should put the arg1
in the render function
Not the outer function
And that, right there, will likely reveal the problem
My guess is that you need to move the let
inside the render functions (and change from a Form-2 to a Form-1). Thus moving the subscriptions (which use the changing value of arg1
) into the renderer itself.
@mikethompson Yes, it changes over time. Cool! Will try it out and let you know! Thanks!
Remember, with a Form-2, the outer function is only ever called once (per component).
The renderer is called many times (each time arg1 change?)