Connect html ui and phaser canvas

[lukaMis]

Anyone doing ui in html over phaser canvas? If so how do you connect ui elements and methods in phaser states? Do you use one main global object?

[mattstyles]

I dont use Phaser but I do it frequently with other canvas renderers (usually I use Pixi or Stackgl stuff).

Think of an architecture where rendering is decoupled from logic, this is almost always a good way to go. Your UI, or, your rendering, can be considered fairly dumb, it simply tracks user interactions and passes those events to the logic, the logic then performs the actions.

If you structure like this then its easy to tie up multiple different rendering layers, such as HTML and canvas stuff, as the logic that you use to change states in your application isnt really concerned with how your application is displayed, it simply performs mutations which update your game state, your rendering layer should then re-render your game and you’ll get a visual representation of the changes that have occurred.

I'm in the camp that discourages globals, but, in some cases it can simply make your job easier (and therefore quicker) if some classes are available all over your application. Taking the global approach is usually great for early development, or fairly trivial applications, but will quickly become a ballache as your application grows. However, libraries like jQuery or Phaser, (where you ordinarily have just a single instance) it makes sense that they are global, even if you use a module system to remove them from the window global context. Really it is up to you and needs of your application whether globals make sense or not.

For me, the major case against globals is that they can be grabbed from anywhere in your code. At first glance this may seem like an advantage, but, it encourages you to use them in the middle of function/algorithms which means that you may be introducing undesirable and/or unpredictable side effects. This can be a real killer.

[lukaMis]

I was not thinking global globals like old school but one global object to namespace everything. 

Like this

var MyGame = MyGame || {};

MyGame.game = new Phaser.game();

MyGame.triggerUi =function () {

// do UI magic here

} ;

Atm I structure stuff like this. As I am Always looking for better options that is the reason I started this topic. 

[mattstyles]

JS being what it is, you're kind of stuck with the namespacing and leak at least one global. There are solutions to this though as namespacing is still pretty horrendous.

There are a fair number of module systems available for use in the browser, they require a build step (yes, build steps are a pain) but allow you to modularise your code a bit better and stop leaking globals. I recommend browserify, although webpack is another popular solution, there are a number of others. I'd say steer clear of AMD solutions like requireJS, modules are coming to the browser and they will not be AMD so not really worth learning, the commonJS style is more intuitive and simpler anyway (learn about all these terms if you dont already know them).

But whether you choose to use `globals` or some other module system is secondary to your question anyway.

Your question could easily be 'How do I connect disparate parts of my application?' or 'How can I let my objects communicate with one another?'

The good news is that these concerns are about as old as programming is, certainly as old as object-oriented programming anyway.

At the moment it doesnt really look like you are making much distinction about the different parts of your application. 

Think about things in a slightly different way. Each action that your application performs could mutate (change) the state of the application. If you take this approach then your UI sections, and any JS that might control them, are simply responsible for turning user events into actions and passing those actions on to other parts of your application that then respond to those actions. The chain is simple, and I'm sure you already know it:

* Register user event

* Convert user event into application action

* Perform state mutation based on action

* At some point, render the new application state

The bit you're asking about is between steps 2 and 3.

The simplest pattern I know to learn about is the publisher/subscriber pattern.

Your UI code are publishers, they publish (or emit) events when they receive user events. Your logic code (or application code, or business logic, whatever you like to call it) are subscribers, they subscribe to publishers so that when the actions are published they are told about it¹ and can respond accordingly. (¹ there a few different ways to tell a subscriber about an action, some do not involve telling! I'm trying to keep things simple so I'll gloss over that detail for now). 

There are many other ways (and many variants of pub/sub) but I think this is the simplest pattern to understand, and it is the one used by the browser itself to respond to user events so any frontend web dev should be very comfortable with it.