Yearly Archives: 2019

Control Add-ins Supercharged: Development and production build tasks

  • Reading time:2 mins read

I’ve been absent for a while – sometimes it’s difficult to find time for blogging even when I want it. Anyway… here’s the last post in the introductory series of posts that explain my NAV TechDays 2019 demos. In this code example, I explain the difference between typical development and production build configurations, and I show how to configure gulp accordingly.

To check the code example, and to read the detailed explanations of it, jump over to https://github.com/vjekob/supercharged_01/tree/08-gulp-build-prod

Continue ReadingControl Add-ins Supercharged: Development and production build tasks
Read more about the article Control Add-ins Supercharged: Babel

Control Add-ins Supercharged: Babel

  • Reading time:1 min read

After a short absence, I am back. The next lesson in the Control Add-ins Supercharged series I am introducing Babel.

“Babel is a JavaScript compiler”, says babeljs.io. So, what’s the big deal, you may ask? The big deal is that Babel will take your super-fancy high-end future-generation JavaScript code that barely any browser supports, and turn it into something that even Internet Explorer can run. In theory, at least. In practice, it’s a bit more complicated.

To learn about theory and practice of Babel in control add-in development workflows, check this branch: https://github.com/vjekob/supercharged_01/tree/07-gulp-babel

And that’s it. The Readme.md file contains all the theory and practice you need. So, navigate to my github and check it out.

Continue ReadingControl Add-ins Supercharged: Babel
Read more about the article Code annotations in AL – Please, don’t!

Code annotations in AL – Please, don’t!

  • Reading time:10 mins read

One of good practices of writing C/AL Code for Microsoft Dynamics NAV since the dawn of civilization was annotating (commenting) code changes. If you are not sure what I mean by that, this is what I am talking about:

While standards varied about > vs +, or < vs -, or what the annotations should include, there was absolute consensus that annotating changes is an absolute must.

And it was a must. It was such an important rule that everyone followed it without questions asked. In my career, I’ve seen one or two situations of somebody changing or deleting a line of code without leaving any comment, and I’ve seen quite a lot of code, believe you me. It was that important.

It was that important in fact that it was one of the first things developers learned when they signed up for the job, and it was one of the rules they all followed from their first day.

Continue ReadingCode annotations in AL – Please, don’t!

Control Add-ins Supercharged: Debugging with source maps

  • Reading time:3 mins read

So far I’ve shown how to configure gulp to help you with some basic JavaScript development tasks, such as bundling and minifying, and how to automate builds on every source file change. Let’s now take it to an entirely new level: debugging.

If you ever tried to debug your control add-in source code using Visual Studio Code, you might have realized two things: first, that it’s actually pretty simple to do; and second, that it’s not the kind of debugging that you want.

Let’s see why that is.

First, using VS Code with a browser such as Chrome, Edge (especially “Canary”, mmmm) or Firefox is easy. There are debugging extensions built for that purpose that allow you to either launch a browser with VS Code attached as a debugger, or to attach VS Code to a running instance of a browser (some browser configuration needed beforehand). However, when you use VS Code as a debugger like this, it’s hardly more than a glorified browser built-in developer tool – the only benefit of using VS Code is that, well, you are in VS Code, rather than inside the browser. However, you are not really debugging your source files – you are debugging scripts currently loaded in the browser. You can’t set debug breakpoints in your source files – you can only set them in copies of files that are loaded by the browser. If you catch a bug (kind of a point with a debugger) you can’t stop the process and immediately change the line where the bug is, but you have to first locate the matching source script, and then the offending line, and then fix it there. Not exactly a fun pastime.

And that’s annoying enough if you have a single script to work with, but if you have several scripts, bundled together, then minified, well, good luck with that. Debugging minified code is as close as you can get to inquisition-level torture in this century.

So, let’s fix this mess, and let’s enable debugging as it should be – let’s enable debugging of actual source files with full breakpoint integration and all.

That’s what my next branch is about. In it, I introduce source maps and how you can use gulp to build them. And then I explain how you can configure your VS Code to debug your source files.

So, head over to https://github.com/vjekob/supercharged_01/tree/06-gulp-debug and check out some pretty cool stuff.

Continue ReadingControl Add-ins Supercharged: Debugging with source maps

Control Add-ins Supercharged: Automating gulp.watch

  • Reading time:2 mins read

Yesterday you’ve seen how to use gulp to make it do something truly useful: bundling your JavaScript and CSS files. Introducing gulp for the purpose of bundling your files allows you to split your functionality into as many files as you want, but use only a single script and a single stylesheet file from your control add-in. That way you not only optimized how your browser loads the files, but you also eliminated the need to maintain your controladdin object file every single time a new JavaScript or CSS file is added (or an existing one is removed).

However, you still need to run gulp build every single time you want to build your bundles. If you forget that, your controladdin will not be updated with your changes.

Thankfully, gulp has an answer to this: the gulp.watch feature. That’s the topic of my next demo, that I’ve explained in the 05-gulp-watch branch of my supercharged-01 repository.

The Readme.md file of that branch explains how to configure the watch task in the gulpfile.js file, and how to configure VS Code to automatically run the watch task every time you open the workspace. Once you follow those instructions, you can work on individual JavaScript or CSS files without the need to run gulp build or to maintain your controladdin object file. The former is taken care of by gulp, and the latter is taken care by… well, gulp too. Gulp is cool, really 😎

Continue ReadingControl Add-ins Supercharged: Automating gulp.watch

Control Add-ins Supercharged: Teaching gulp some useful tricks

  • Reading time:1 min read

My last demo introduces gulp, an amazingly simple task automation tool. You’ve seen what it is, how to set it up, and how to create a simple hello-world task. Now it’s time to teach gulp some useful tricks and make it automate the “build” process for the JavaScript and CSS files.

The first demo in this series uses a single-file approach, and there I stated that it’s a bad thing to develop like that. It’s bad to put all the functionality in one single file. However, that rule applies for development, not for runtime. Your browser actually prefers using a smaller number of JavaScript (or CSS) files. That’s why typical runtime JavaScript libraries are bundled. On top of bundling, you’ll also want to minify your JavaScript and CSS files to make them as small as possible, to further improve the download and initialization speed.

These are the things that today’s demo uses. So, head over to the https://github.com/vjekob/supercharged_01/tree/04-gulp-useful branch, and check out how to configure your gulp to build your JavaScript and CSS bundles from your source files.

Continue ReadingControl Add-ins Supercharged: Teaching gulp some useful tricks
Read more about the article Control Add-ins Supercharged: Hello, gulp!

Control Add-ins Supercharged: Hello, gulp!

  • Reading time:2 mins read

Get ready for the next big step in taking the control add-in development to the next level. Today, I am (re)introducing gulp.

I’ve blogged about gulp in the past, but I’ve never really finished that series. Life and work got in the way. But while I may not have blogged about it much, it’s been my companion for quite some time now, and now I want it to become yours, too.

In previous “Control Add-ins Supercharged” examples we’ve mostly explored how not to do things. Now we are ready to take a look in the opposite direction and start talking about how to do do things.

For this example, I’ll use my next demo branch 04-gulp-hello-world that you can check out here: https://github.com/vjekob/supercharged_01/tree/03-gulp-hello-world.

I don’t intend to copy/paste all the theory explained in the branch’s Readme file, but I’ll just say what you can find there:

  • Steps to install the prerequisites to run gulp
  • Steps to install gulp and make sure it works
  • Examples how to run gulp tasks from both command line and VS Code
  • Just a tiny little bit of theory around Node.js packages
  • A few good practices around some Node.js artifacts that will appear in your workspace once you install gulp

And with this small example that introduces gulp I conclude the introduction into the “Control Add-ins Supercharged” series. All the next steps will deliver ready-to-use stuff that you can plug into your own control add-in development process, and we’ll start building our toolchain step by step.

Have a great weekend!

Continue ReadingControl Add-ins Supercharged: Hello, gulp!
Read more about the article Control Add-ins Supercharged – Frameworks

Control Add-ins Supercharged – Frameworks

  • Reading time:2 mins read

In the last example I put online, we’ve noticed that it was difficult to achieve a good separation of concerns in the front end if we are building UI directly through DOM. Apart from the fact that it’s very inefficient, manipulating DOM directly makes it very difficult to structure your front-end logic. You quickly realize you need a framework for that.

And here I come to a big fat point I want to make once again, that I made in my session, too: don’t build a new framework; pick one off the shelf.

The thing is, in the JavaScript world there are ridiculously many frameworks. This article on Hackernoon is an introduction into this total insanity: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f. There are memes, jokes, comics, websites, even Alexa skills that address the fact that people keep creating new JavaScript frameworks all the time. Guess what? A tiny fraction of them generate any traction at all, and only a few stick.

And don’t get me wrong – I am totally for improving things; “the room for improvement is the largest room in the world” they say. But I am not quite convinced that building a yet another framework will benefit the posterity all that much. If you want to improve on what we have, most of the leading frameworks are open-source, contribute away.

As with previous (and future) posts in this series, there is a GitHub repo + branch that accompanies this blog post, and you can find it here: https://github.com/vjekob/supercharged_01/tree/02-framework

(The featured image used under CC license from https://worldpece.org/content/how-standards-proliferate)

Continue ReadingControl Add-ins Supercharged – Frameworks
Read more about the article NAV TechDays 2019 Goodies

NAV TechDays 2019 Goodies

  • Reading time:2 mins read

NAV TechDays is simply the best NAV / Business Central conference there is. I can miss Directions, I can miss other events, but NAV TechDays – no way. There are few events which can match that energy, that community spirit, that enthusiasm, that top-notch deep-dive content. No, there are not few that can match it; there are none that can.

And then when you consider that they manage to attract ever more people to it, all that while publishing all conference content less than a week after conference is over – it just proves to you that the value of NAV TechDays is not in its content or its sessions. Being a part of NAV TechDays has always been an honor, and a pride, and a privilege.

No matter if you were there last week or not, you’ll want to access the conference materials, so here are the links:

Since this is my blog, I’ll also link directly to my Day 1 session about control add-ins development: https://www.youtube.com/watch?v=_IjppPvkmgE

I’ll post the direct link to Waldo’s and mine Day 2 session about APIs as soon as it is available.

Day 2 content is now also available, so here’s the link to Waldo’s and my session about Business Central custom APIs, {ConnectApps}²: https://www.youtube.com/watch?v=9yg-8tLNjzg

Enjoy the content – and see you again next year in Antwerp!

Continue ReadingNAV TechDays 2019 Goodies

Control Add-ins Supercharged – Separating concerns

  • Reading time:2 mins read

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.

Continue ReadingControl Add-ins Supercharged – Separating concerns