Share internal identifiers and message types with the JavaScript client

[javan]

Move internal messages to ActionCable::INTERNAL and sync window.Cable so we don't have to maintain them in two places.

cc: @lifo

[lifo]

Looks great to me!

[dchersey]

I am using this within a non-sprockets client app (ember-cli) talking to a rails backend.
Can you suggest the best way to include this client library in a way that has rails populate Cable.INTERNAL from the server as this change requires?

Thanks!

[javan]

Perhaps you can lean on your Rails backend to compile the cable js for you? How were you building the js before this commit?

[dchersey]

Prior to this commit there did not seem to be a dependency on the rails pipeline; I have it in the ember-cli pipeline managed by broccoli. I am just in the process of getting that to work however so I am not sure that is true but it looks that way. I'm working with a version just prior to this commit. I'm also working in parallel on putting this latest version into a test example served by rails views and I will see if I can then leverage that.

…

On Nov 12, 2015, at 9:28 AM, Javan Makhmali ***@***.*** wrote: Perhaps you can lean on your Rails backend to compile the cable js for you? How were you building the js before this commit? — Reply to this email directly or view it on GitHub.

[javan]

I'm not familiar with ember-cli or broccoli. Do they support Sprockets directives for requiring other files? https://github.com/rails/actioncable/blob/master/lib/assets/javascripts/cable/consumer.coffee#L1-L4 for example.

[dchersey]

Ember-cli uses a completely different pipeline for assets, based on javascript. It's kind of 'rails-for-ember' in that it organizes your ember app according to convention-over-configuration and provides its own asset pipeline.

It uses a mix of bower, npm and broccoli for different purposes. The net-net though is that there's no ERB preprocessor so actioncable's embedding the internal references in cable.coffee.erb requires sprockets to be in the pipeline somewhere.

This effectively limits non-rails-based javascript UIs from being actioncable clients, and I wonder if that is worth gaining the value of injecting these internal values from the ruby code.

Fortunately for me, there is ember-cli-rails which serves ember-cli based clients via the rails asset pipeline -- after some fiddling and cursing I managed to get this working :)

[lsylvester]

I think that non sprockets asset manages will need to use precompiled versions of action cable where the erb and sprockets require directives have already been evaluated. I see no reason that a precompiled version of the cable javascripts couldn't be distributed for non rails users.

[dchersey]

That's a good suggestion; perhaps that should go in the doc as well.
I'll give it a try if I move back to straight ember-cli (not served by rails) ... still debating pros/cons of that gem.

Previously to this commit I was including the js in the ember-cli asset pipeline; it was fine because it was all javascript and no ERB.