If you know me, you know that I am obsessed with separation of concerns. It’s the core principle of good design, and good design is what I am always striving for.

The original Control Add-ins Supercharged example showcased how most of non-web developers (a category into which most of AL developers squarely fall) would develop a control add-in: just stuff everything into a single script, and all is fine. But it isn’t fine, if for nothing else, then because it can be done much better.

My next example is showing how you might attempt to solve the separation of concerns issue. The first step you may take is splitting the single script file into multiple files. For example, you may separate UI logic from state management logic, from AL-to-JavaScript interface logic. However, the example I am presenting today is yet an example of a good solution. It’s in fact a yet another “don’t do it this way” example. There are a few more wrong steps I want to intentionally take before I start solving problems for real, one by one.

The primary issue that my second repo (branch 01-split-js) addresses is that it separates front-end concerns as much as reasonably possible. However, as you will see in the repo description, once you attempt to separate logic into multiple JavaScript files, the separation of concerns isn’t really achieved, and there are a few files where you still have a mish-mash of UI, data, state, events, precisely those things that shouldn’t go together. The problem is, whatever way you attempt to solve it, you soon realize that the solution is just not good enough. As long as you are attempting to generate and maintain your UI using pure DOM, it will be impossible to achieve any decent level of separation of concerns.

So, head over to https://github.com/vjekob/supercharged_01/tree/01-split-js and check out the repo description (and content) and see for yourself why this approach is better than the previous one, but still far from good.

See you soon with the next example.

Control add-ins have always been my passion. Not only because I’ve been working with JavaScript since 1996, and I could call it my mother tongue, but because I just love how they allow us to create amazing user interfaces. Business Central has made huge progress in terms of usability of the web client, however it’s still not the most user friendly thing out there, and performing some tasks may be tedious. Control add-ins help because they allow us to develop custom user interface over standard data and processes.

However, when building control add-ins, it’s not only about what we build, but also about how we build it. That was the central tenet of my NAV TechDays 2019 session named “Control Add-in Development Supercharged”, in which I wanted to show how control add-in development can be indistinguishable from modern web front end development. Because that’s exactly what it is – web front end development.

For my session I’ve prepared total of 36 demos. However, I realized just before the session that I won’t be able to deliver all of them, while also delivering all the theory I wanted to present. So I decided to post all of the demo source code for all 36 demos. However, this year I wanted to take a step further: I wanted to not only deliver the code as-is without any explanations, I actually wanted to explain all of it.

And this is what this blog series will be about – how to supercharge the control add-in development and make it as modern as it can possibly get. All with code examples and explanations. In the end, you’ll get a nice tutorial of modern control add-in development, that I hope will help you build your skills and take your control add-in development to the next level.

All code examples and explanations will be in in GitHub, and the first example is already there.

So, head to https://github.com/vjekob/supercharged_01 and check out the first example.

I won’t be posting code explanations here on my blog, I’ll merely be posting about the latest contribution to my GitHub repositories, and will add a line or two to explain what a particular repo or branch are about.

So, today: repository supercharged_01, branch master.

This branch introduces the “Simpler” control add-in and sets the stage for all further demos. It contains a very simple AL extension that contains a control add-in. The control add-in does not provide a feature-complete functionality, but merely showcases how it could be possible to simplify an otherwise less user-friend process. Keep in mind that the control add-in itself does not matter. What matters is its structure and how it was created.

In this branch, the control add-in is done in a “naive” way, how a typical AL developer without much experience in JavaScript or web development would develop it.

Stay tuned for (far) more content over the following days and weeks – it takes time to explain 36 demos in detail.