Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Flow and nodejs #10

stigi opened this Issue · 6 comments

2 participants


There are several issues when using flow within nodejs.
For one, it would be nice if flow could be integrated as a module (npm would be great! :))
Therefore it would also be necessary that it wouldn't expect GSet in the it's scope but rather require it too.

The other thing is, it expect's this to be a window. This is not the case in nodejs.

I worked around all of this by adding the following lines:

GSet = require('../deps/gset-min.js').GSet;
this.clearTimeout = global.clearTimeout;
this.setTimeout = global.setTimeout;

I've got one more issue where _main isn't called, i'll try to debug into this.

Just so you know :)



Hi stigl,

Thank you for sharing where Flow needs improvement! I will update this bug and address your nodejs concerns in the nextgen branch - my current development focus. Also, I appreciate your suggested directory structure regarding dependencies, since that too is something I've struggled with.

Admittedly, I haven't communicated the significance of the nextgen branch well. In short, the master branch was a proof-of-concept with several performance and integration problems, due primarily to my over-use of GSet. That said, besides the README, there is no documentation for the nextgen branch. Please accept this cursory outline, for now.

  • Flow is now an event-loop platform.
    • Fires begin when instructed to navigate states.
    • Fires traverse when a state is traversed during navigation.
    • Fires end when navigation is halted or completes (i.e., after the target state is entered).
    • The platform is extensible via named modules of code, called packages.
    • Each Flow "instance" is two or more objects:
      1. A private instance, managed by the Flow platform.
      2. A public instance, returned to the user.
      3. A package-instance, created for and managed by each package.
  • Packages determine the platform's behavior and capabilities.
    • Only packages can respond to platform events.
    • Packages define and manage the public API.
    • For instance, the behaviors of the master branch are now implemented by the core package.
  • Depends on genData instead of GSet.
    • genData is a data-processor, and does not substitute GSet - a proxy-object generator.
    • The nextgen brach is focused on interoperability and performance, which doesn't mesh with GSet's high number of closured calls.
  • The Flow API is 30% smaller.
  • The "_main" component is now the "_on" component (by default).
  • Smaller footprint (under 5K gzip'd).
  • The codebase is 90% feature-complete.
  • Using Qunit for simpler testing and comprehension.

I hope this outline makes using and understanding the nextgen branch more attractive. I will merge that code into the master branch, update the wiki, and publish an api-demo website by 2012. Also, again, I'll update this bug once I've implemented a nodejs solution in the nextgen branch. Thanks for your patience!


I'm going to make a large commit this week, which will include commonJS branching. I'd like your opinion on my approach.

What once depended on the window and genData, like so:

!function (window, Array, genData, undefined) {
  // ... define Flow, then...
  // expose Flow
  window.Flow = FlowAPI;
}(window, Array, genData);

Will now use exports and require(), like so:

!function (env, Array, genData, undefined) {
  // ... define Flow, then...
  // expose Flow
  env.Flow = FlowAPI;
}(this.exports || window, Array, this.require ? require('genData').genData : genData);

I'm not at the point of testing this, but do you think this is a viable solution?

I'll be updating genData to be commonJS compliant too. Also, in the nextgen branch, setTimeout() and clearTimeout() are no longer affixed to the window object, which should handle any scoping concerns.

@bemson bemson was assigned

Thanks for all the feedback. Will have a look later today or tomorrow.



I just made genData an npm module, which is (should be?) commonJS compatible. I learned how there is no "this.exports", just an "exports" keyword, and the same goes for "require()". I ended up using a lengthy @typeof@ check, to branch functionality for commonJS/Node and browser environments.

!function (genData) {
  // Define Flow, which uses genData, then...
  // export or expose Flow, based on the environment
  (typeof exports !== 'undefined' ? exports : window).Flow = Flow;
}(typeof require !== 'undefined' ? require('genData').genData : genData)

I'll use that experience when making Flow commonJS friendly. Of course, we'll both see how it actually works then! I'll be sure to close this bug, when I commit these changes in the nextgen branch - likely next week!


I've finally published my changes to Flow and the core module. The changes support exporting Flow to node, but I have yet to test it. Also, I need to note when to use the nextTick method instead of setTimeout (when the delay is 0ms).

I'm busy with the holidays, but wanted to update the thread. Do inform me, if you have time to test it, whether Flow loads properly in node. (Note that you'll need to install genData beforehand.) I'll check myself in the new year.


Though the nextgen branch solved months ago, I finally merged it with the master branch, as Flow version 0.3.0 commit 2b104ec.

Running node flow-min.js revealed no errors, so I'll flag this as closed for now. Thanks very much for engaging on this so long ago. I welcome making Flow work for you in the future!

@bemson bemson closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.