Fork me on GitHub
#rum
<
2016-09-02
>
asolovyov06:09:22

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

levitanong06:09:50

@asolovyov Will check Posh out! thanks man.

niwinz08:09:20

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.

martinklepsch10:09:27

@niwinz how does this work? Like how does a lens know that it's used or not?

martinklepsch10:09:57

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.

niwinz11:09:45

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

niwinz11:09:07

and later you have some helpers that derives an atom like object from an other with a lense

niwinz11:09:41

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

martinklepsch11:09:04

right, I think I follow until that point

martinklepsch11:09:54

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?

niwinz11:09:52

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

niwinz11:09:19

if you deref a derived atom, you are just derefing the original atom, and applying to it a transformation

niwinz11:09:36

this is more inneficient that the derived-atom if you want to deref multiple times

niwinz11:09:41

the derived atom...

niwinz11:09:56

but the good stuf comes when you mix the lenses based derived atoms with rum

niwinz11:09:03

and its reactive mixin

niwinz11:09:14

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

niwinz11:09:01

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

niwinz11:09:44

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

niwinz11:09:17

I'll try to create a small example of this for clarify

martinklepsch11:09:13

I think I understand.. mostly. 🙂

martinklepsch11:09:02

> 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

niwinz11:09:40

yes, this is exactly how it works

niwinz11:09:00

the user trigger to the derived atom will be only triggered if the data is changed

niwinz11:09:38

@martinklepsch just wait 5 min, I prepare a little and descriptive example that will make understand that more easy

martinklepsch11:09:04

cool, awesome, thanks for taking the time, very much appreciate it 🙂

martinklepsch11:09:22

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

niwinz12:09:12

@martinklepsch I'll take a look on that ASAP

niwinz12:09:49

I think your derivatives is very similar to lentes .. 😛

niwinz12:09:35

in fact as quick view, derivatives is pretty equivalent and has the same purpose of lentes

martinklepsch12:09:16

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

martinklepsch12:09:22

So when I use a lens in 15 components, the lens computation is applied 15 times when the source atom changes, yes?

niwinz12:09:32

yes, at this moment yes

martinklepsch12:09:38

so there's no kind of caching in that way

niwinz12:09:45

but the next version will come with performance improvements

niwinz12:09:47

in this area

niwinz12:09:34

I'm using lentes extensively in uxbox codebase and the concept works pretty well

martinklepsch12:09:48

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

niwinz12:09:08

I have plans to introduce not lazy version to lentes also

martinklepsch12:09:25

non-lazy as in triggered by watch?

martinklepsch12:09:03

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)

niwinz12:09:09

and knowing that derivatives exists maybe I will change the opinion

niwinz12:09:35

@martinklepsch I know, I have seen your issue in the rum's github

martinklepsch12:09:24

At that point integrating it in an application becomes trickier but I guess with rum mixins it's not that hard

niwinz12:09:30

The cool stuff about lenses, is because they are composable in the same way as you can compose transducers

niwinz12:09:35

with simple comp

martinklepsch12:09:36

Hm, I see why that conceptually is cool but what's the practical difference to plain functions operating on data? (as done in derivatives)

niwinz12:09:46

I'm not very convinced with watch based derived data, but I don't have real arguments agains them

martinklepsch12:09:09

(this of course assumes a watch based approach)

niwinz12:09:30

I think they are the same as transducers

niwinz12:09:38

composability without boiler plate

niwinz12:09:43

bi-directional

niwinz12:09:47

In some way, lentes implements the concept of lenses thar are described as the functional way for composable getters and setters

niwinz12:09:25

after better view on derivatives, seems very nice piece

niwinz12:09:34

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.

niwinz12:09:33

An other maybe interesting option can be just join the forces and integrate the two libs in one having the both approaches...

martinklepsch12:09:37

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

niwinz12:09:23

The lenses approach has two advantages, composability without much boilerplate and bi-directional (not only getters, lenses also offers composable setters)

niwinz12:09:47

if you don't need anything of that, lenses does not have any additional advantage

martinklepsch12:09:17

Right bi-directionality is something I'm not interested in and I guess the getter related composability might not be significant over regular fns

niwinz12:09:51

it is pretty significant I think but You can't valorate it with simple examples

martinklepsch12:09:47

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

niwinz12:09:43

this is the reason because of existente of different approaches 😉

martinklepsch12:09:14

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

niwinz12:09:57

In the same way as I 😉

niwinz12:09:07

maybe with a simple cross reference is more than enough

niwinz12:09:27

and in future we will how the things are evolved 😉