Efb app development process optimisation?

I’m familiarising myself with the efb app development process, so took the sample template app for a test run.
https://docs.flightsimulator.com/msfs2024/html/7_Samples_Tutorials/Samples/Misc/EFB_Template_Sample.htm

As I understand it now, this is what you have to do to build/deploy/modify/test in sim:

  1. Follow EFB Template App readme to install/build ts/js src to dist folder
  2. Follow EFB TEMPLATE SAMPLE and use dist as the source, build all project on sim devmode to create package
  3. Load the created package into community folder
  4. Open sim, run Coherent Debugger, select Select the efb page in the debugger to monitor it and to see output when using app in efb
  5. Make changes in js/ts src, run npm watch to build to dist folder, then also need to rebuild the project each time with SDK project build all command and it will auto reload into the debugger, or refresh Coherent debugger to reload.

Do I have this process right, as the optimal way to develop and iterate test for the efb?

It’s a lot more convoluted than iterating on a toolbar app, though I can understand why given the nature of it.

Is there any way to optimise it, to speed up the development test/iterate cycle beyond the double build?

Some more complex examples would also be helpful to understand what’s going on and give some guidance/ideas of how to use/access more complex integrations. eg: the current efb apps are great but can’t read them for guidance.

What are the disadvantages/advantages of toolbar apps vs efb apps?
Can you jam any app idea into either (like the current apps pop up 2d as well as in efb) or are there some considerations that make a toolbar app a better deployment vs efp app, or vice versa?

Thanks!

1 Like

Good question. Our EFB in MSFS 2020 is based on HTML Intruments, during the development, with some additional adaptation and mockup, I could use a normal browser to see changes. It was also easy to see the changes in the sim by reloading…

regards
ROB

I would vote for this too, if possible ^^ Very complicated workflow or simple tasks.

I don’t think Build All in the Project Editor is needed. Maybe except for the first time. Then you can run WATCH to auto-build or build manually in VS Code whenever you want then just manually copy (maybe run a batch file after each build?) the contents of the DIST folder to the PACKAGES and refresh (CTRL+R) the coherent debugger.

This is a really good issue to raise. Node / typescript / components are ok for classic webapp development but ultimately it’s just a build alternative for JS. Commercial webdevs love it (not least it’s a good career move), but for a lot of other people it just gets in the way. The unexpected and probably unplanned issue in MSFS2024 is the assumed ‘strategic’ api’s for model XML, gauge JS, simconnect and wasm are radically deteriorating wherever the EFB app is involved seemingly with an idea ‘if everyone worked in the node / typescript / components toolset everything would be fine’.