Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error when calling imitate multiple times #138

Open
wclr opened this issue Nov 3, 2016 · 5 comments
Open

Error when calling imitate multiple times #138

wclr opened this issue Nov 3, 2016 · 5 comments

Comments

@wclr
Copy link
Contributor

wclr commented Nov 3, 2016

I wonder how imitate called multiple times should behave. Or it should be allowed to be called only once with an error thrown for example.
http://www.webpackbin.com/4kKOgnNxM

import xs from 'xstream'

let interval1$ = xs.periodic(200).mapTo(1).debug('interval1$')

let interval2$ = xs.periodic(1000).mapTo(2)


let source$ = xs.create()

source$.imitate(interval1$)

setTimeout(() => {
  source$.imitate(interval2$)
}, 1000)

source$.take(10).addListener({
  next: (x) => console.log(x)
})

Though it could be interesting to allow multiple times imitate call with proper unsubscribing from previous source.

@staltz
Copy link
Owner

staltz commented Nov 4, 2016

Imitate only exists to enable circular dependencies. It's unfortunately an imperative API, and I think it shouldn't be able to call it multiple times because then we're allowing dynamic circular dependencies, and this starts to get confusing very fast. We could make it through an error in that case, but it would only add more code to the bundle.

Let's keep in the list as an idea.

@staltz staltz changed the title calling imitate multiple times Error when calling imitate multiple times Nov 4, 2016
@wclr
Copy link
Contributor Author

wclr commented Nov 4, 2016

but it would only add more code to the bundle.

Don't get me wrong, I know you care much about resulting bundle "size", but this issue: adds much more to current cycle bundles then potential couple lines of code that can make things safer 😉

@staltz
Copy link
Owner

staltz commented Nov 4, 2016

I agree, and I'm still up for accepting a PR for that issue. The difference is that xstream is a much more foundational library than Cycle DOM. xstream is a dependency everywhere in Cycle.js, so its bundle size is more important.

@wclr
Copy link
Contributor Author

wclr commented Nov 4, 2016

I agree, and I'm still up for accepting a PR for that issue.

I think it (makeHTMLDriver) should be properly be extracted and documented maybe @TylorS could accomplish it. If no one will, I will someday 😄

xstream is a dependency everywhere in Cycle.js, so its bundle size is more important.

In most real cases it is supposed to be included only once per bundle, so it is not more important then any other component's size (esp dom driver for front-end web apps).

@staltz
Copy link
Owner

staltz commented Nov 4, 2016

In most real cases it is supposed to be included only once per bundle, so it is not more important then any other component's size (esp dom driver for front-end web apps).

I didn't mean it would be included multiple times. I meant it will always be included, so it will determine the minimum size of any Cycle.js app. But anyway, we are not in disagreement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants