Better error handling for dispatcher.register about flux

[fisherwebdev]

Yeah that's a good idea. It would be nice to use the invariant module that
is a dependency of the dispatcher for this. But I think we have not
exposed it in the npm module, so maybe we should do that.

@zpao, any thoughts on this?

[zpao]

require('flux/lib/invariant') will work for node & anything using browserify/webpack. This is how it's "exposed" with React as well. I don't think it should be exposed at the top level, it's weird (require('flux').invariant feels wrong, invariant is entirely unrelated). Ultimately we want to get to a point where these shared dependencies are not duplicated and bundled like this and they are usable in a sane way for third parties. But in the mean time, the relative module path works.

[gnesher]

I've had a chat with a few colleagues and it feels like implementing this within the dispatcher would make more sense (otherwise each store fires an error).

Adding a simple action validator method on the Dispatcher dispatch method is rather straight forward and require 0 code change from the users. Does this sound sensible?

[fisherwebdev]

Yes, sounds great. Really great idea. Looking forward to the pull request!

[gnesher]

#59 is this ok?

[fisherwebdev]

Answered in the pull request, but basically, I'm concerned that the dispatcher would need to know the structure of the payload.

[gnesher]

Since the examples all seem to follow this specific implementation I just assumed this was the intended way to use the actions.

I understand the problem, though if I'm completely honest - I'm not sure that enforcing specific structure / naming conventions are necessary bad.

I've been using Backbone for a good while now, and the biggest hurdle in learning how to use it properly is what I consider to be fake freedom that they offer. It seems amazing at first, but as soon as you start building bigger applications you begin to stumble into quite a few problems.

Now the community did come up with best practices and certain tools / wrappers (like Marionette) were invented but this (in my opinion again) is too little too late - and frameworks like AngularJS just gain huge traction.

Now I'm not suggesting to turn Flux into anything that all encompassing, but I'm also weary of leaving these (and others?) known issues to the individual implementation just for the sake of what seems like edge cases?

Obviously just my own opinion here :)