UI logic choices

I already have this separation:

*CmpActionSelect*: C++ native component that controls which action is active for the entity.
*ActionSelectWindow*: Javascript browser class that displays an action select HUD.

Whenever *CmpActionSelect* does something, it needs to tell *ActionSelectWindow* to update. I have these options:

1.  Finish complete object replication feature that allows Javascript code to inspect native objects. *ActionSelectWindow* then periodically polls state of *CmpActionSelect* or reacts to specific object/property changes remotely.
2.  Send RPC messages from *CmpActionSelect* to *ActionSelectWindow* whenever new actions are selected.
3.  Create an intermediate native component that reacts to event changes in *CmpActionSelect* and sends RPC messages to *ActionSelectWindow*.

To start with, I luckily don't have to deal with the nastiness of putting UI logic in game code. It's impossible for me to do that because there's a physical process separation between game and UI. Which is nice.

I'm not considering 1 as a solution because it requires a week's worth of work that may or may not be useful for other features in the pipeline. It's a distraction. It would be fun to work on but it will cost me time and money now for benefits in a future that may not exist.

So the decision is between 2 and 3. 3 seems "better" because it separates game logic from the logic that updates the UI (if I had another UI method to display the same state, I don't have to modify *CmpActionSelect*).

However, I've gone with 2. It's much simpler code with less indirection and is something that I can code now with minimal cost. If it wasn't for the RPC layer I already have, 2 could easily be made worse. As it stands, it looks quite elegant!