These are chat archives for canjs/canjs

30th
Dec 2016
Thomas Sieverding
@Bajix
Dec 30 2016 00:28
@justinbmeyer I responded on the issue. I think your approach is overkill
Kefir is a strict subset of RxJS, so there’s an opportunity to make can-stream / can-define-stream decoupled from the underlying FRP lib
Justin Meyer
@justinbmeyer
Dec 30 2016 01:17
@Bajix there's not a way to do a drop in substitution given the limitations of module loaders
every module loader has it's own way of doing things
and what would really be gained?
Thomas Sieverding
@Bajix
Dec 30 2016 01:23
If there is a more flexible way of doing this that allows authors to simply use can-stream / define-stream and swap out the frp as needed, then authors wouldn’t need to favor one over the other when their use cases are accomplished by either
Justin Meyer
@justinbmeyer
Dec 30 2016 01:23
what would be the way of doing this?
@Bajix
Thomas Sieverding
@Bajix
Dec 30 2016 01:24
I’d prefer to use author w/ kefir & allow users to swap in RxJS
Hmm
Justin Meyer
@justinbmeyer
Dec 30 2016 01:24
then they can if they want to setup a map rule on kefir
to rxjs
if they are that similar
(but they aren't identical)
(which is a problem)
Rx.Observable.create(function (observer) { vs Kefir.stream(function (emitter) {
and to setup compute <-> stream behaviors ... we need to create streams in this way.
Thomas Sieverding
@Bajix
Dec 30 2016 01:27
That part is definitely different, but could be managed through a thin wrapper
Justin Meyer
@justinbmeyer
Dec 30 2016 01:27
yes, that wrapper will be in the individual can-stream-X libs
so if people need, they can do a map on that ...
but I don't know how that affects the proposed package topology
Thomas Sieverding
@Bajix
Dec 30 2016 01:29
Yea. I think just structuring things so that’s a viability would be a good first step
Justin Meyer
@justinbmeyer
Dec 30 2016 01:30
isn't it already?
I think some other way via can-namespace where people have to configure can.STREAM = Kefir would be a mistake
Thomas Sieverding
@Bajix
Dec 30 2016 01:32
Ideally we could avoid the need to have can-define-stream-x and just have can-stream-x
Justin Meyer
@justinbmeyer
Dec 30 2016 01:33
can-define-stream will be the "bindings"
so you can pass it any can-stream-x ... and then you have the right mixin
I want to avoid any sort of super dependency
in CanJS's code base
Thomas Sieverding
@Bajix
Dec 30 2016 01:35
can-namespace is a safe super dependency
Justin Meyer
@justinbmeyer
Dec 30 2016 01:35
it's not a super dependency
it's a dependency
Thomas Sieverding
@Bajix
Dec 30 2016 01:36
What do you mean by the term super dependency then?
Justin Meyer
@justinbmeyer
Dec 30 2016 01:37
requiring some injection of configuration prior to modules loading
Thomas Sieverding
@Bajix
Dec 30 2016 01:39
If can-stream-x had toCompute monkey patched then can-define-stream wouldn’t need to know about the stream
Justin Meyer
@justinbmeyer
Dec 30 2016 01:40
yes, and it wont
that is in the proposal
however ... can-define-stream won't depend on a underlying stream library
Thomas Sieverding
@Bajix
Dec 30 2016 01:41
That’s fine though
Justin Meyer
@justinbmeyer
Dec 30 2016 01:41
it just exports a function that takes a can-stream-x and produces a mixin
ok ... so I still think it's nice for people not to have to do: defineStream( canStreamRXJS )( Type);
hence the can-define-stream-x
however, if you want to make modules that can take a can-stream .. something like the following would work
widgetThing( { stream: canStreamRXJS })
and eventually if you want to make some can-stream compat target ... allowing something like:
Justin Meyer
@justinbmeyer
Dec 30 2016 01:46
widgetThing( { stream: canStream( toCanStream(RXJS) ) })
Thomas Sieverding
@Bajix
Dec 30 2016 01:46
can-define-stream-x seems like the best option at this point
Justin Meyer
@justinbmeyer
Dec 30 2016 01:46
I'm cool with that
:P
Thomas Sieverding
@Bajix
Dec 30 2016 01:47
I just like exploring options ;p
Justin Meyer
@justinbmeyer
Dec 30 2016 01:49
yeah, that's good
Thomas Sieverding
@Bajix
Dec 30 2016 01:51
It might be better for the growth of CanJS to push towards RxJS over Kefir
Thomas Sieverding
@Bajix
Dec 30 2016 02:46
@justinbmeyer There’s no longer anything similar to %root now right?
I’ve been finding it really cumbersome to cross-binding to route.data within templates
Nico R.
@nriesco
Dec 30 2016 07:30
@Bajix I also tried in the past to use %root in my app design but what you should really do is create bindings https://v2.canjs.com/docs/can.view.bindings.html http://canjs.com/doc/can-stache-bindings.html
Thomas Sieverding
@Bajix
Dec 30 2016 08:20
@nriesco Yea, but the probelm is that something like<can-import from=“can-route” {^value}=“*route”/> isn’t always stable
read about that
its near the same in donejs
there are in general diffrent concepts of data sharing
like the root concept
the data component concept
and so on
and it depends only on size of application and development team size whats best
so for single coders the root concept is always valid
root concept is as simple as fetching all state via app.js === viewModel and share it fully or partial with sub components
Thomas Sieverding
@Bajix
Dec 30 2016 08:23
The problem is getting a reliable reference to route.data
Frank Lemanschik
@frank-dspeed
Dec 30 2016 08:24
@frank-dspeed
does any one know when i use done autorender i have $("html").viewModel(); // -> AppViewModel for accessing the view model
will $('my-component').viewModel() work also?
i am just courios
:D
cc @justinbmeyer @matthewp @phillipskevin
@justinbmeyer
it does
@frank-dspeed
thanks a lot
did you read that?
Thomas Sieverding
@Bajix
Dec 30 2016 08:24
I’m talking about within a template
Frank Lemanschik
@frank-dspeed
Dec 30 2016 08:24
yes
i am also
:D
Thomas Sieverding
@Bajix
Dec 30 2016 08:25
If you use can-import to pull in can-route, there are some cases in which data might not be set immediately and things will break
Frank Lemanschik
@frank-dspeed
Dec 30 2016 08:25
ever tryed to insert <script></script> into a stache template?
it gets rendered
and then executed
if data don't gets set immiditly
new Promis()
is the way to go isn't it?
simply return a promis in your component
and then use it with .then in the other
your familary with that already i think as far as i saw your code contribution it looks like your realy uptodate
i return on all async actions always promis
i stoped the call back stuff
Justin Meyer
@justinbmeyer
Dec 30 2016 15:10

@Bajix

Yea, but the probelm is that something like<can-import from=“can-route” {^value}=“*route”/> isn’t always stable

what do you mean by "stable"?
Frank Lemanschik
@frank-dspeed
Dec 30 2016 15:11
he meand the value is not a promis
so it is not clear that it is resolved when component is loaded
he runs a long running function inside the component and loads the component in a other
and wants to reuse the value there
Thomas Sieverding
@Bajix
Dec 30 2016 16:20

what do you mean by "stable”?

@justinbmeyer *route.data can’t be assumed to be defined, and when it isn’t, bindings will fail. The least race-condition prone approach is to do <can-import from=“can-route” {^value.data}=“*route”/> and wrap your template with a conditional, but it would be a lot better if autorender could prevent this timing issue from being possible.