Component runs twice, isolated child components lose scope/namespace

[wyqydsyq]

I have an app with a bunch of nested components and have found that when I use cyclic-router, the component that's being loaded (Welcome) gets called twice, causing isolated child components with implicit scopes (e.g. export default sources => isolate(UserProfile)(sources)) lose track of their scope because it seems the scopes are recalculated when the component is reran.

If you git clone https://github.com/wyqydsyq/hapi-cycle, run npm install && npm run launch and then visit http://localhost:1337/ you can see the UI in this case works fine, but if you then swap the part of https://github.com/wyqydsyq/hapi-cycle/blob/master/src/ui/app.js that returns just the component with the commented out lines to make it use cyclic-router instead of calling the component directly, subcomponents will no longer emit/recieve events from/to themselves.

Using explicit scopes seems to remedy this, as each isolated child component would be using the same scope string in between calling the main component, but that's more of a band-aid fix than a solution.

So the working/not working cases for me are:

• ✅ Router with explicit isolation scope on child components
• ✅ No router (calling component directly) with implied isolation scope on child components
• ❎ Router with implied isolation scope on child components

[ntilwalli]

https://github.com/wyqydsyq/hapi-cycle/blob/master/src/ui/app.js#L10

I haven't tried your code but you def need to multicast your routes$. In xstream that's done with remember(). Your function is probably being called twice because you have two sinks that are creating independent closure chains up through the Welcome call, instead of sharing one component emitted from the route.

See example doing this here:
https://github.com/ntilwalli/routingWithState/blob/master/main.js#L91

[wyqydsyq]

Ah right I was just going by the example on the readme which doesn't mention it needing to be multicast (though it makes sense that it should be, someone new to Cycle/xstream like myself wouldn't think of that). So I guess the only actionable thing from this issue is to mention that in the docs.

Sorry I'm not sure what you mean by sinks making independent closure chains, could you please further explain or give an example of this?

Thanks.

[ntilwalli]

Sure. I was being too wordy. If you understand that it needs to be multicast then you understood my point.

For completeness though, the below code will create an object but it won't start emitting until
addListener is called on it:

const a$ = xs.periodic(100).take(5).map(x => x*2)

When you call addListener, a set of closures/functions are created at that time (you can think of a new closure being associated with each operator, in this case the operators are periodic, take, and map) and they call each other in a chain from source to sink ("source" being periodic and "sink" being the functions in the object given to addListener.

Each call to addListener creates a new closure chain, up to the source unless the chain is interrupted by a multicast, in which case the upstream chain is shared.

const a$ = xs.periodic(100).take(5).map(x => x*2).debug()

// Will print 0 0 2 2 4 4 6 6 8 8 10 blue 10 green because each stream below creates an
// independent closure chain
a$.addListener({next: x => {}, error: e => {}, () => console.log(`blue`)})
a$.addListener({next: x => {}, error: e => {}, () => console.log(`green`)})

const b$ = xs.periodic(100).take(5).map(x => x*2).debug().remember()

// Will print 0 2 4 6 8 10 blue green because the streams below share one
// closure chain up to the remember
b$.addListener({next: x => {}, error: e => {}, () => console.log(`blue`)})
b$.addListener({next: x => {}, error: e => {}, () => console.log(`green`)})

[ntilwalli]

Actually, I just remembered xstream is multicast by default. remember is used to replay the the last value for late listeners. xstream is a newer library so what you experienced may actually be a bug. I'm pretty sure it's not a cyclic-router issue. If remember fixes the issue then it seems to imply that under the hood remember forces an explicit multicast... dunno.

[wyqydsyq]

Using .remember() seemed to fix it on Chrome Version 51.0.2704.103 (64-bit) and the latest Safari Tech Preview, but it made no difference on a slightly outdated Chrome (~v49) or on Safari Version 9.1.2 (11601.7.7) which is strange because I'm using the babel polyfill + es2015 preset so assumed it should work the same. Maybe V8 and Apple's new js engine have changed their event loop implementations, affecting streams or something?

Either way it seems this is indeed an xstream bug, but I've only been able to reproduce it when using cyclic-router so far.

[TylorS]

Hi guys, thanks for the conversation here! I've been very busy and haven't been able to give this repo much love. PRs are graciously welcomed. Let me know if you would like to be added as a collaborator, I can also probably add you to npm to do new publishes 👍

[wyqydsyq]

So I put the app I'm having this issue with up on Heroku and have found something pretty strange - using .remember() on my router stream did fix it in newer browsers locally, but for some reason when served from Heroku the issue resurfaces in the same browsers it works locally in, you can see it in action here:
https://hapi-cycle.herokuapp.com/

If you look at the console when initially loading the page (or clicking one of the buttons that changes the current route) you'll see it's logging component names, and doing it multiple times. These are just from a single console.log() at the top of each component, so you can see it's executing them multiple times.

But when running this exact same app locally, with the same webpack config, the issue doesn't happen and the output is logged once per component.

I'm still trying to make sure this isn't just an error on my part, and pin down where this is happening so I can write a reproducible test/example of it. But it really boggles me as to why it's working for me on localhost in latest browsers, but not at all in older browsers or when served from Heroku. I assumed something in my webpack config/build was breaking it, but even with doing a webpack build with export ENV=production and serving that bundle locally it behaved exactly as my development build (that is, works locally on new browsers, breaks when hosted or using slightly older browsers).

[ntilwalli]

@wyqydsyq I dunno. I love the goals of xstream, and I've used it a lot, but it is young and def has some bugs. If you have the patience to endure and investigate this issue among others, cool. Otherwise I recommend you switch to another stream library and see if that fixes it.

[TylorS]

Apologies for slow response here, and thank you for the discussion. I currently do not have the time to investigate this. I would love for some help and a community contribution.

[TylorS]

@wyqydsyq As a potential workaround you could ensure that isolate is only called once, but this may have other issues if you try to use the component multiple times as sibilings to one another.

- export default sources => isolate(Component)(sources)
+ const isolatedComponent = isolate(Component)
+ export default sources => isolatedComponent(sources)

[ntilwalli]

@TylorS I'd love to be a collaborator, but I don't have anything to contribute yet! Cyclic-router does what I need for now. If I need a feature it doesn't have I'll def ping you abt it and collaborate for sure. :) I find this lib very useful.