Your turn favicon badge

[haoyangnz]

When it's a player's turn, update favicon with badge using https://github.com/ejci/favico.js.
This helps the user to play long-running board games while doing other things by notifying them it's their turn.

[nicolodavis]

Love the idea!

[nicolodavis]

The library you linked to hasn't been maintained for some years now though.

We can probably get good mileage by just changing the page title to something like:
"(1) boardgame.io"
to indicate an unread message or that it is the player's turn to play.

[haoyangnz]

Yea I realised that - will look around to see what we can do.

[nicolodavis]

Another option to explore would be the Web Notifications API, although this should probably be an opt-in feature because the UI is more intrusive.

Both this and the title prefix should probably be opt-in (the user needs to set a boolean on the <Client> component to true) for it to be enabled.

[haoyangnz]

The library you linked to hasn't been maintained for some years now though.

We can probably get good mileage by just changing the page title to something like:
"(1) boardgame.io"
to indicate an unread message or that it is the player's turn to play.

I think the badge would still be nice compared to title change (for pinned chrome tabs).
And I couldn't find any alternative to https://github.com/ejci/favico.js, other than https://github.com/tommoor/tinycon, which is only slightly more maintained. Would you be open to us using https://github.com/tommoor/tinycon?

Also, how do you think we should implement this? Something will need to change on Board?

[delucis]

I wonder if this could be developed as a plug-in? It seems like a good candidate for something that users could add optionally rather than an essential part of core. (If there are technical reasons he current plug-in interface can’t support this, it would also be an opportunity to look at improving that.)

[nicolodavis]

The plugin interface is mostly concerned with game logic and the general API of the framework. I don't think plugins should be involved here.

However, I'm definitely supportive of the idea that users that don't want this feature should not incur a cost. It's easy enough to turn it on / off via a boolean prop in <Client/> (which is where I think this should be implemented).

However, what about bundle size cost? If we're pulling in an additional dep, we should make it possible to not include it in the bundle if users don't want it.

[delucis]

Yes — I was just coming to that realisation too. I wonder if it could be a hook that you don’t need to import if you’re not using it?

For example, maybe <Client> could have a plugins prop, which is an array of hooks or objects defining plugins?

Then you could do:

import NotificationPlugin from 'package'

<Client
  plugins={[
    NotificationPlugin,
    // ...
  ]}
/>

We’d need to figure out exactly how to implement the interface within Client for consuming plugins/passing state etc. I’m not sure what best practices are for this kind of situation.

At the simplest a plugin could be a function that takes an object with all the state variables or something:

const Plugin = ({ ctx, playerID }) => {
  useEffect(() => {
    // update badge
  }, [ctx.turn])
}

[nicolodavis]

We used to use https://www.npmjs.com/package/react-json-view to render G and ctx on the Debug Panel before we realized that it was almost doubling our bundle size and it didn't make sense as a default. That might be a good candidate for an optional add-on as well.

Some of the material here might be relevant: https://reactjs.org/docs/code-splitting.html

However, we are moving everything to Svelte (#432), so ideally we'd implement something that doesn't have to be rewritten drastically.

[delucis]

What if this kind of functionality could be shipped as plug-ins to the vanilla JS client? (Rather than tying it to the React <Client>.)

Notifications in general — in <title>, the favicon, using the Web Notifications API, playing an alert sound, etc. — could be used in some way similar to what I suggested above, but without the React-specificity. Would that need some new client code? Something like an event listener model, where you could attach a plugin to onTurnBegin or onGameOver or whatever? (I’ve been using the React client, but I’m not sure how the store and data-binding works using the vanilla client.)

[nicolodavis]

That's exactly what the Svelte migration is trying to achieve (make a lot of this type of code available to the vanilla JS client). Svelte just compiles down to plain JS that can be included with the vanilla JS client. We could also write some plain JS to implement the present feature being discussed (i.e. it doesn't have to wait for the Svelte migration necessarily).

We don't currently have a good mechanism to tap into events like onTurnBegin from the client. There is an open issue for this actually (#360).