Customizable service worker

[maxence-charriere]

Summary

• App worker template can now be changed from HTTP handler
• App worker template is now exported under the DefaultAppWorkerJS variable.

[maxence-charriere]

@oderwat is that provides what you need?

[oderwat]

Yes, it should. I need to recover an old branch and try it (we are currently on hold about push notifications because of the iPhone situation, but that seems to resolve this year).

[maxence-charriere]

@oderwat Is there anything else you would need to consider go-app for a production candidate ?
I kind of want to release the next version.

[oderwat]

@maxence-charriere I am pleased with the v9.6.0 branch and have few left to wish for in general.

You could think about deprecating app.If()+related, though. I did not check if you added a warning about the (prominent but easy to forget) evaluation and told the user they might want to use an anonymous function instead.

An idea for a useful extension was adding a "debouncer" in the update chain. I thought of delaying updating after a given count of frames (or a time but then in the next frame) without updates. This would be like preventing the update but putting it in a queue and resolving it as soon as there were no more updates for that given number of frames. In that context, I also wondered if getting a frame counter from the app would be possible. I have places where I delay something using time where I really just want to wait after the next update.

The other extension I would love is basically the same as PR #562. I think that functionality could remove the need for globals. Currently, we are using Twirp for creating frontend/backend communications. To make the client available to all the components that use it, I have different ways: A global variable in a special package (global), adding components from the root and initializing them (for components from different repositories), or even just grabbing the page URL and doing a full client implementation in the component (wasting resources). To get the initial client setup and bind them with the start of the root component, I need to transfer some information from the place where I set up the route with the component (type) to the actual creation of that component. For example, I can switch between JSON and Protubuf messages by a CLI flag. That flag is already transferred over the "app.Env." The instantiated client is then transferred using a global variable. This could be cleaner when the route would call a factory function, which could use a closure to add parameters. This factory function then emits the actual component instance and could initialize something like the API client and even add other shared functionality. I do not like using the messages + state observers for that, as they are typeless and async, making the setup harder to handle and understand.

But, as I said above, I am happy with v9.6.0 already.