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.
