This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-02
Channels
- # beginners (61)
- # boot (84)
- # cider (43)
- # cljsrn (2)
- # clojure (99)
- # clojure-android (3)
- # clojure-austin (2)
- # clojure-italy (5)
- # clojure-russia (43)
- # clojure-spec (93)
- # clojure-uk (41)
- # clojurescript (94)
- # clojutre (1)
- # cloverage (8)
- # core-async (31)
- # cursive (3)
- # datomic (14)
- # defnpodcast (1)
- # editors-rus (7)
- # events (1)
- # hoplon (15)
- # leiningen (3)
- # luminus (6)
- # om (142)
- # onyx (86)
- # other-languages (4)
- # pedestal (1)
- # planck (1)
- # portland-or (5)
- # re-frame (96)
- # reagent (16)
- # ring-swagger (17)
- # rum (73)
- # specter (25)
- # untangled (14)
- # yada (142)
@levitanong: what I did was something like derived-atom (it is in rum right now), which are instantiated and removed in mixins. It subscribed to results of a datascript query and components rerendered only if data changed. Of course then problem is that on db change all those atoms recalculate - but you can mitigate that, there is a library for that called posh.
@asolovyov Will check Posh out! thanks man.
You also can mitigate the problem using funcool/lentes
, that exposes similar stuff that derived-atom but the resulting derived atoms are laizy and they are only recomputed if you are using them. In contrast to derived-atom that is always recomputed independently if you are using it or not.
@niwinz how does this work? Like how does a lens know that it's used or not?
I'm toying with extending @asolovyov's work with derived-atom
so that these derived-atoms can be used dynamically. There needs to be some mechanism to "free"/"dispose" them to clear the watches on relevant source atoms.
@martinklepsch lense is a concept with that you can define a composable getter and setters in a functional way, in the practice they are implemented in the same way as transducers (function composition).
and later you have some helpers that derives an atom like object from an other with a lense
that atom is completly lazy, when you deref it, the original atom is derefed and the getter lense is applied and then the result is returned to the user
right, I think I follow until that point
What happens if now the deref'd atom is no longer used and the original atom changes? Does that not cause recomputation because it's not (no longer) being dereferenced?
the derived atom is just an other atom with the exception that it does not holds any data, it just holds a reference to the original atom and an lense (in simple words a function that applied to the value of atom and return an other transformed value).
if you deref a derived atom, you are just derefing the original atom, and applying to it a transformation
when you attach a watcher (that rum reactive mixin does) to a derived atom, the that watcher will be triggered if the original atom changes
but the derived watcher is only triggered if the previous value of the original atom applying it the lense and the current value applying the lense are different
With that, you can have a lot of derived atom that does nothing and does not penalize performance until they are directly watched by the rum component
I think I understand.. mostly. 🙂
> when you attach a watcher (that rum reactive mixin does) to a rum.core/derived-atom
, the that watcher will be triggered if the original atom changes
Is that true? I think the watch will only be triggered if the resulting value differs
@martinklepsch just wait 5 min, I prepare a little and descriptive example that will make understand that more easy
cool, awesome, thanks for taking the time, very much appreciate it 🙂
btw, don't know if you've seen https://github.com/martinklepsch/derivatives — would be curious if you have any feedback. I find a lot of the stuff you build under funcool/ and also the whole UXbox codebase very good/learned a lot from it so you seem like a good person to ask for feedback. 🙂
@martinklepsch I'll take a look on that ASAP
in fact as quick view, derivatives is pretty equivalent and has the same purpose of lentes
I think what lentes might not have is the dependency tracking/dynamic creation of derived data but then again maybe this is not necessary given the fact that lentes
is "on-demand", i.e. computation is triggered by deref vs derivatives
where computation is triggered by watches
So when I use a lens in 15 components, the lens computation is applied 15 times when the source atom changes, yes?
so there's no kind of caching in that way
Cool 👍 practically many of the derived pieces of data I have in my application are not very computationally intensive so probably not a huge issue often
non-lazy as in triggered by watch?
If you do that you'll also need to introduce some sort of lifecycle to remove the watches (at least that's something I'm missing from rum.core/derived-atom
)
@martinklepsch I know, I have seen your issue in the rum's github
At that point integrating it in an application becomes trickier but I guess with rum mixins it's not that hard
The cool stuff about lenses, is because they are composable in the same way as you can compose transducers
Hm, I see why that conceptually is cool but what's the practical difference to plain functions operating on data? (as done in derivatives)
I'm not very convinced with watch based derived data, but I don't have real arguments agains them
(this of course assumes a watch based approach)
In some way, lentes implements the concept of lenses thar are described as the functional way for composable getters and setters
I think that instead of spending time implement similar stuff on lentes, I will link you repository for any one that want use watch based derived atoms. I know that derivatives is not 100% equivalent, but it is ok for now.
An other maybe interesting option can be just join the forces and integrate the two libs in one having the both approaches...
I don't think I fully understand the benefits of lenses yet but maybe it's just that I haven't had a relevant problem or so
The lenses approach has two advantages, composability without much boilerplate and bi-directional (not only getters, lenses also offers composable setters)
Right bi-directionality is something I'm not interested in and I guess the getter related composability might not be significant over regular fns
That said sometimes I wonder what it would be like to break out of the "grand unified loop" established by re-frame et al. There are situations where it seems appropriate but then again it feels like it'll haunt me later
Regarding derivatives. It currently has a dependency on Rum which I'll probably remove as I implement the disposable derived-atom (still looking for a better name). After that I'm happy to consider merging or having links to it. I'd just like to keep dependencies to an absolute minimum. 🙂