Fork me on GitHub
#funcool
<
2017-01-06
>
martinklepsch05:01:37

@niwinz is there some utility or so in beicon that helps me turn a callback based API into a stream?

martinklepsch05:01:51

Could probably whip up something myself just wondered if there’s some utility for that 🙂

martinklepsch10:01:42

I guess a debouncer mixin might be better since I can reuse that easier in other components

martinklepsch10:01:49

Hm. Something with my get-completions! function is still wrong, Can’t get the StartPlacesAutocompletion. Seems when I merge one ended stream with another one it ends it too? Or something like that? 😄

martinklepsch10:01:59

Ah! — rx/subject!

martinklepsch11:01:59

Hm, still doesn’t quite work...

niwinz14:01:04

@martinklepsch (rx/map (fn [x] (get-completions! serv x)))

niwinz14:01:25

it should be mapcat

martinklepsch14:01:33

I tried mapcat

niwinz14:01:39

then I think that get completions is also wrong

martinklepsch14:01:56

yeah, I think the culprit is somewhere in that get-completions fn

niwinz14:01:59

it returns a stream that never finishes

niwinz14:01:16

that is the objective of get completions?

martinklepsch14:01:27

Also tried rx/end instead of rx/push!

martinklepsch14:01:37

The objective is to return a stream with one item

niwinz14:01:41

so rx/push!

niwinz14:01:45

and then rx/end!

niwinz14:01:53

(rx/end! subject)

martinklepsch14:01:51

uh, weird. I tried (end! subject thing) and thought it would put thing on the stream and end it.

niwinz14:01:52

On the end you have two ways convert callback code to rx streams returning code

niwinz14:01:05

using rx/create or using rx/subject in the way as you have used it

martinklepsch14:01:07

There was no exception for the (end! subject thing)

niwinz14:01:12

with the finally calling rx/end! on subject

niwinz14:01:55

the thing is just ignored because end! only has arity 1

martinklepsch14:01:18

right but shouldn’t it cause an error then, calling a function with wrong arity?

niwinz14:01:28

no, in javascript no...

martinklepsch14:01:33

maybe I’m remembering wrongly what I did, will re-check later

martinklepsch14:01:44

oh, ok, that’s rough 😄

martinklepsch14:01:59

never consciously ran into that

martinklepsch14:01:20

@niwinz generally would that be the approach you would take or would you use component lifecycle, decouple debounce & actual action, .... ?

niwinz14:01:58

It depends, but if you want to debounce, probably I will use the component stuff

martinklepsch14:01:59

I guess question is if you think this is a good area for RX over other solutions

niwinz14:01:12

debounce for UI stuff

niwinz14:01:06

on the other hand, this not looks bad

martinklepsch14:01:26

I’m also tending towards using component lifecycle now mostly because I can make the debounce stuff separate to the action I’m doing after debounce

martinklepsch14:01:41

(which is coupled here and not really nice I’d say)

niwinz14:01:07

I agree with that