DEV Community: Ville M. Vainio

Your Angular app probably doesn't need SASS

Ville M. Vainio — Mon, 13 Jul 2020 18:52:09 +0000

As it turns out, using SASS can slow your Angular build a lot. This may come as a suprise, since SASS, when run from command line (either dart-sass or the C++ based node-sass) can churn through tons of files in few seconds. When used in Angular components, however, you could be looking at one minute of just parsing SASS in medium-large application with hundreds of components.

At this point you will be asking "so why are we using SASS in the first place" - and it probably boils down to:

$variables
Nesting
Mixins
No harming in doing that right?

Variables are the trivial part - you can replace them with CSS Variables (or "CSS custom properties" if you are a cop). This can be done with a well-placed script run, but you need to be careful about calling calc() when SASS was just computing a value directly.

Nesting is something you thought you wanted but actually you possibly don't. Since component styles are already scoped per-component, you can usually refer to single css class .foo without requiring it to be child of :host, which is child of .my-section etc. In fact, lot of nesting creates a lot of unnecessary bloat in the output .css files. Moreover, the whole :host thing is only needed to style the topmost, "host" element. ::ng-deep (which we pretend to be deprecated) will work just fine in .css files.

Mixins - odds are you are overusing them. If you have a base style called .btn and you include .btn in several places, consider just saying <button class="btn my-buttonish-thing"> in your .html files. The "macro" capability of SASS could be considered competing and inferior to using the native browser feature of, well, supporting CSS classes that add styling to your elements.

Eject!

At this point, you will be looking for exits. So here's one path:

Write a script to extract your $variables to my-arr-variables.css
Write a script to run node_modules/.bin/sass.cmd to all your *.component.scss files. Keep the ones that didn't explode in size due to overzealous use of SASS features and leave the rest as SASS.
Keep your global top level styles as .scss files, but do consider compiling them outside ng build and referring them as plain .css files (i.e. not referring to them from angular.json, just add a <link rel="stylesheet" href="my-global-styles.css">

On (not?) splitting big .NET applications to assemblies

Ville M. Vainio — Mon, 06 Jul 2020 16:35:26 +0000

This only applies to .NET, and to large code bases fully controlled by you (preferably in a monorepo).

There are good dependencies, and bad dependencies.

Bad dependency

Depends on a big framework (asp.net, wcf, ef, DI containers, etc.)
Depends on several own assemblies
Depends on a third party library
- There are some exceptions in every product, e.g. NewtonSoft.Json, System.Reactive etc. can be "universal"
Has significant business logic code
- ...and therefore can change frequently

Good dependency:

Is mostly declarations. POCOs, constants, enums, interfaces, attributes.
Can be compiled in the beginning of your build.
Can be compiled when your services are running (check OutputPath!)
Doesn't change often. It's "ready".

You can bundle a lot of good dependencies together to same DLL without cost. If your DLL is less than 100kb, it's possible it
can be merged with other small DLLs to simplify your dependencies and speed up the build. Instead of Feature.Foo.dll and Feature.Bar.dll, consider if you could just have Feature.dll if those two libraries depend on same things.

Contrary to naive intuition, fine grained DLL's are not efficient and usually not desirable. You are not selling them separately, or distributing to other applications. When you need to add new DLLs (e.g. because it provides integration with some new third party library or service), consider if there are other DLLs you could get rid of in your code base.

You can add a reference to a good dependency without sweating it much. Most probably, you are already depending on it so you don't need to.

Namespaces for internal code don't really matter. Don't overbloat your pull requests by adjusting them constantly.

... except when they matter, and you have abominations like NetDataContractSerializer hiding somewhere. Stay safe!

Notes from a local NuGet package development workflow

Ville M. Vainio — Sun, 08 Mar 2020 10:14:44 +0000

Note: this is not a production-proven workflow, take it as lab notes I wrote while I still remembered how it works.

When developing a NuGet package, you easily end up with situation where you depend on another package published from the same (mono)repository.

Example:

I have FastExpressionKit targeting netstandard2.0
I have FastExpressionKit.BulkInsert targeting net472 (because netstandard2.0 is missing System.ComponentModel.DataAnnotations)
I have FastExpressionKit.Test that runs tests against both of the libraries.

FastExpressionKit.Test needs to use ProjectReference instead of PackageReference, because you couldn't run the test suite against unpublished packages. You also want a fast edit/run inner development loop.

I solved this dilemma by doing the following for each csproj:

$ dotnet pack -c Release /p:Version=1.1.0 /p:PubVer=1.1.0

Here, PubVer is the toggle that switches on PackageReference. Excerpt from FastExpressionKit.BulkInsert.csproj:

  <ItemGroup Condition="$(PubVer) == ''">
    <ProjectReference Include="..\FastExpressionKit\FastExpressionKit.csproj" />
  </ItemGroup>

  <ItemGroup Condition="$(PubVer) != ''">
    <PackageReference Include="FastExpressionKit" Version="$(PubVer)" />
  </ItemGroup>

When running tests, PubVer is not defined and ProjectReference is activated. That wasn't so bad, especially since you can slap the Condition on ItemGroup instead of reference itself.

Local feeds

In order to create a package for FastExpressionKit.BulkInsert, it needs access to FastExpressionKit package. For a version you don't want to publish yet. Hence we publish it to local feed immediately after dotnet pack:

$ dotnet nuget push -s c:\localfeed .\bin\Release\FastExpressionKit.1.2.0.nupkg

In order to actually use this local repository, you have to create file called NuGet.Config (case sensitive!) with content (adjust relative path accordingly):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="local" value="..\..\localfeed" />
  </packageSources>
</configuration>

When this is in place, PackageReference will find the FastExpressionKit package from that local directory.

Why do it like this???

NuGet, unlike pip or npm, doesn't have built-in support for this workflow so tricks are needed
Paket.local doesn't support SDK-style project files
For convenience, the version of all NuGet packages in the FastExpressionKit "package family" is the same, i.e. one specified by both PubVer and Version
I didn't really run those commands, I have publish.py script that does these steps. For the sake of historical correctness, here's the snapshot of the script:

from pathlib import Path

import os,shutil

LOCAL_FEED = Path(r".\dev\localnuget").absolute()

projects = ["FastExpressionKit", "FastExpressionKit.BulkInsert"]
version = "1.2.0.0"
def c(s):
    print(">",s)
    err = os.system(s)
    assert not err

def nuke(pth):
    if os.path.isdir(pth):
        shutil.rmtree(pth)

def nuget_add(pth):
    c(f"dotnet nuget push -s {LOCAL_FEED} {pth}")

startdir = Path(".").absolute()

for prjdir in projects:    
    os.chdir(startdir / prjdir)
    nuke("bin")
    nuke("obj")

    def pack():
        c(f"dotnet pack -c Release /p:Version={version} /p:PubVer={version}")
        pkgs = list(Path("bin/Release").glob("*.nupkg"))
        nuget_add(pkgs[0])

    pack()

Got a better workflow that is not a massive MsBuild XML library? Let us know in the comments!

Trivial, typesafe translations in Angular

Ville M. Vainio — Wed, 17 Jul 2019 13:22:38 +0000

The official Angular translation system (angular-i18n) is problematic in various respects (read this ticket and thread in ngx-translate project for background):

Discussion: future of the library #783

ocombe posted on Jan 30, 2018

Hello everyone, I'd like to discuss about the future of this library and get your opinion on my plans.

(Long) history

You can skip that part if you don't care about how this library came to life

When I started this library 3 years ago, I wanted to learn Angular and I thought that working on an open source project would be the best way to do that. It had worked for me on AngularJS with my library ocLazyLoad that was a huge success (2600 stars) and whose core principles were finally integrated into the framework in v1.6.7.

At the time I was looking for a way to translate my Angular apps and found out that there was nothing in Angular to do that (i18n wasn't even existing in the framework). I asked my good friend Pascal Precht if he was interested in porting angular-translate from AngularJS to Angular but he wasn't and told me that I should do it.

My library quickly became popular for various reasons (no real alternative, I had a good reputation from my work on ocLazyLoad, my appearances in Angular Air and my talks at conferences). And I guess that the code was good enough and easy to start with. It was also a time where the framework was still in beta, and there were no real guidelines for publishing libraries for Angular, it was so hard to do it that not a lot of people were trying and I didn't have any real competition on i18n for a long time.

Some time later, the library ecosystem started to settle and Angular was stable, they decided to drop the name Angular 2/4/... in favor of just "Angular". I decided to rename this library ngx-translate and to use npm scopes in order to deliver a modular experience. I rewrote the whole library and made it possible to replace some parts (loader, parser, compiler, ...). It was still a side project for me, but I was using it at work because we had finally started using Angular in production and needed to translate the app in multiple locales.

The official i18n implementation was super complicated (and still is), it didn't support json, code translation, changing the locale without reloading the app, and you needed multiple app bundles (one per locale). My library was so popular that I wanted to work on it full time because I could see that it was a necessity for the Angular community. It solved a lot of use cases, and was simple enough to be usable in a few minutes.

I decided to quit my job and see if I could make a living out my open source work. I knew that it was possible because ag-grid had done it and they were very successful. It was in December 2016, I had 2 months left at work before I was free, and I went to the conference NG-BE where Igor Minar from the core team was present. I wanted to ask him some advices on how to turn this into a profitable OSS project, but before I could tell him about my plans, he told me: "Ah Olivier, I wanted to talk to you, you've got to stop working on your library [ngx-translate], Companies come to us and want to do i18n, but they only talk about your library, we want them to use our solution [Angular i18n] because it's more efficient".

I was a bit speechless, I was there about to tell him that I had quit my job and wanted to work full time on my lib, and he was asking me to stop working on it. So I did what anyone with a bit of common sense would have done, I told him that Angular i18n sucked, that it failed to deliver the promise of easy-to-use-yet-powerful that they wanted Angular to be. I probably didn't use those words, but he agreed with me that it still needed some work, but they didn't have enough resources to work on it (Victor Savkin and Jeff Cross had just left the team to create Nrwl). I jumped on the occasion and told him that I would love to work with them to improve Angular i18n. He told me that he would consider it, and we left it at that.

A few weeks later, and recontacted me, and told me that they were ok to hire me as a contractor to work on i18n. It was like Christmas for me (actually it was around Christmas, so that might explain it) because working for Google is a once in a lifetime opportunity and a dream job. But working on open source, from home, for Angular, it was even better and I didn't even thought that it was possible for me to do that.

I joined the team in February 2017 (almost a year ago), and started working on i18n. There was a lot of work to do, but I was confident that I could make a difference. It was clear to me at the time that it would take a few months to make i18n easier to use for everyone, with the features that people wanted, and that I could deprecate my library after that.

It turns out that working on a framework like Angular is super complicated. The codebase is huge, not highly documented, with a lot of different packages. The development process is complicated (it doesn't even work on Windows yet), and whenever you make a change you have to be extra careful not to break anyone. We even write tests, like a lot of tests! It was a big shift for me, because I had always worked on projects that needed to ship fast, and tests were clearly not the priority, you fixed bugs instead. But working on a library like Angular is totally different. Millions of people depend on your code, when you make a mistake you can break applications that loose thousands or hundred of thousands of dollars because of you. The responsibility is overwhelming and that's why it is much more complicated to release new features. I also wasn't the one deciding the priorities for the framework. Any change that you want to make has to work with Google applications, and it's not like you can duplicate functionalities to make it work for everyone (who said forms and http?).

Anyway it was complicated to change the way i18n worked in Angular. I learned a lot and I feel like we're going in the right direction now. I understand the choices that they made for Angular i18n, it's the most efficient and stable way to translate applications. It works very well for huge companies like Google, but it just isn't what most developers need/want.

During this year, I haven't really worked on ngx-translate. The issues are pilling up, I've only merged a few PRs and some of them have been waiting there for a long time without any activity because of me. There are some long term issues that I haven't taken the time to fix (code splitting / lazy loading, testing, ICU expressions, bugs with ionic...).

But before we get to that, let's quickly compare my library with the native implementation.

Angular

In Angular, you translate your templates using an extraction tool that generates xmb or xliff files, which are well defined formats that have been battle-tested. Those files are translated using professional tools, by real translators. At the end you merge the translations at build time and get a translated bundle.

Advantages:

The translation process is well defined, it is easy to detect missing translations and you can integrate that in your plans before deploying your app (extract, send to translators, merge)
It scales well, you never look directly at the files since you use a software for that, you can translate in x languages, you just need to extract once and create the translation files for each locale (which your professional tool should do for you)
it's super efficient because the app is pre-translated when it bootstraps, there's no extra work to apply your translations and it works well with pre-rendering because of that
since you merge the translations at build time, it means that it can support directives, components and other html elements, you can move them around in the different languages, or even remove them if needed
you don't need to worry about lazy loading, your bundles are translated at build time, and that includes your lazy loaded modules

Issues:

it takes a lot of work to setup, you need to extract, send to translators, and then you can merge
you create one app bundle / locale, which means that you cannot change the locale at runtime, you need to reload a different bundle for that. And to do that you need to handle server side routing to deliver the correct locale bundle. Google doesn't feel like it's an issue because you're not supposed to change your locale frequently. And in fact most of your users will change it maybe only once, or not at all. But it still complicates the workflow a lot.
no code translations, only template are translated since that's all you can do at build time for now
harder to use in development because you need to stop your dev server, extract translations, merge them. And the setup is different between JIT and AOT...
you cannot translate libraries, and that's a real problem for components libraries (like material, ng bootstrap, ...)

ngx-translate

With ngx-translate you load the module and configure it, you then load the json files containing your translations. You need to manually define keys for your translations and to write them in your json files that you will probably translate yourself, or transform into other formats that you'll send to your translators. But it's ok because json is easy to manipulate and generate.

Advantages:

you can choose how you want to handle your translations (bundled, http-loaded, pre-cached using service workers or localstorage, etc...)
you can change the locale at any time
it works in your templates AND in your code
json (that's all I need to say)
the community can work on plugins, custom loaders, tooling, etc... everything is hackable and you should be able to make it work the way you prefer

Issues:

it uses bindings (via a pipe or a directive) which means that it works at runtime and you can experience some kind of FOC effect (flash of content) when the translations are loaded and applied. Also it takes some memory and some processor time when change detection is triggered
if you want to split translations, it doesn't work well, the setup is complicated and there are bugs in the library
json is not an official translation format, and most professional translation tool don't handle that, but you can use different loaders to support other formats (like po) so that's not a super huge issue
it's hard to test
if it breaks, then your app will have no text!
it doesn't support angular elements (components, directives, pipes) because there's no "compile" at runtime for AOT applications

Changes in Angular

Like I said, I've been working on Angular i18n for almost a year now. I've actually worked on a lot of other things as well, and the changes in i18n were clearly not the priority for the framework. A lot of internal changes were also necessary before we could do the changes that we wanted.

I've greatly improved the documentation (i18n guide), I've created demo projects with and without the cli to help people get started. I've worked on bugs, and made a few changes, but we've not released anything major for translations.

Finally for v6 the big changes are coming, translating will be done at runtime. Having access to the internals of the framework means that it will be way more efficient than what ngx-translate does. You shouldn't experience the FOC effect, and it won't take any resource during change detection. You'll be able to do code translations, at last! There will only be one bundle per application for all of the locales (or multiple, if you prefer). And libraries should be translatable.

What will not change:

you'll still have to extract translations using the extraction tool and merge them at build time, which means that's it's not very easy to use in development
there's no json format yet (we've been discussing internally about opening the API so that developers can write their own serializers if they want)
it'll still be more complicated to setup and to use than ngx-translate
you can translate at runtime in your code, but the templates will be translated at bootstrap, which means that you cannot change the locale without reloading the app
new features will still take a long time to be implemented, because we don't have the freedom that a library like ngx-translate has

So what about ngx-translate future?

This has been a long post, and we're finally getting to the part where we talk about the future of ngx-translate. The way I see it there are 2 solutions:

1/ we continue like it has been for the past year, only merging a few PRs, not working on new features and not improving the workflow. I keep working on making Angular i18n better and hopefully people will stop using this library because the native solution will be better. Or maybe a real alternative will emerge (like https://github.com/robisim74/angular-l10n).

2/ I change the way I work and decide to spend more time on the library (at least 1 day/week) to improve it: fixing lazy loading, code splitting, adding functions to help with testing, support ICU expressions, create well documented and maintained examples, finally tackle ionic and other mobile issues, ... I focus on making sure that the library stays a viable alternative to Angular i18n by providing solutions to the "problems" that Angular i18n will not fix. I write better tooling, maybe even an editor for the translations. I rewrite the documentation, on a real website with shiny examples.

To do all of that, I would need to make this library profitable somehow. I was thinking about changing the license to require companies to pay for the library (while keeping it free for open source and personal projects) in exchange for priority support (for bugs fixing, and for working on the features that they want the most). Obviously the current version would remain free and MIT-licensed, since there's no legal way to retroactively change a license, and it would be stupid to do that anyway. But new versions would be using this new license.

This library is downloaded ~350 000 times / month on npm now, if you compare that to the ~2 400 000 downloads of @angular/core, it means that my library is used in 1 out of 7 Angular projects! That's crazy, and it gives me confidence that this is viable.

What do you guys think? Would your companies be willing to pay for a better ngx-translate? Do you see any other alternative?

View on GitHub

Since we can't wait for Ivy to happen, we deployed our own translation system that has barely any code or logic (as opposed to ngx-translate that has a bunch).

As preparation, grab files from ngx-pttx github project and copy them to your project (no npm package created yet).

The approach

You need to have the translations available in a hierarchical JSON structure. An example (in en-US.json) would be:

{
  "mygroup": {
    "mykey": "Hello my english text"
  }
}

Your application will download this once it knows what file to get (i.e. what language is chosen). The format may be familiar from angular-translate from your wild Angular 1 years.

Then, you set the strings to be available globally by injecting TxService and doing setStrings():

export class AppComponent {
  constructor(
    private txService: TxService
  ) {}
  ngOnInit() {
    this.fetchStringsSomehow.then(strings => this.txService.setStrings(strings));
  }

Now you can just use txService in various components:

const text = this.txService.instant("mygroup.mykey");

// warning: this can crash at runtime
const text2 = this.txService.txs.mygroup.mykey;

In templates you can use ptTx pipe:

<span>{{ "mygroup.mykey" | ptTx }}</span>

Or ptTx directive:

 <span ptTx="mygroup.mykey"></span>

Now you may ask - how is that type safe? Well, it isn't.

Since you want type safety (to ensure your strings keep working and to get intellisense), you need to create type definitions. We do it in a build step, with quicktype.io command line application. Point it to the translation json file (one, typically english, is enough for type generation):

yarn quicktype --lang ts --no-maps --just-types --out gen/translations_common.ts ../../some_dir_to_translations/en-US.json

Now, we can use txService.make() to create a function that checks the type and gives you the string. It takes the quicktype-generated type as type argument:


import { MyUiStrings } from "./gen";

  private getLocalizedTexts() {
    const tx = this.txService.make<MyUiStrings>();

    return {
      someText: tx(s => s.mygroup.mykey)
    };
  }

That's all?

Yeah, that's all you need to do. You need to provide a few parts by yourself:

Figure out where to fetch the json files.
call setStrings() before your app is drawing components. You can use APP_INITIALIZER provider for this.

RxJS and Angular, I'm not feeling it

Ville M. Vainio — Tue, 02 Jul 2019 08:56:45 +0000

I read an article by on creating custom Closure builder for Angular, and apparently the "Architect" (yes, that's the name of the system) relies heavily on RxJS for consistent API.

Build Angular Like An Architect (Part 1)

Stephen Belovarich ・ Apr 2 '19

#angular #javascript #devops #webdev

Yet again, I'm thinking how much easier people would have it if we (Angular community) were ok to use Promises where they made sense. Here's an example snippet from the article:

return of(context).pipe(
    concatMap( results => ngc(options, context)),
    concatMap( results => compileMain(options, context)),
    concatMap( results => closure(options, context) ),
    mapTo({ success: true }),
    catchError(error => {
      context.reportStatus('Error: ' + error);
      return [{ success: false }];
    }),
  );

This is what it would look like with promises (in 'async' function):


try {
  await ngc(options, context);
  await compileMain(options, context));
  await closure(options, context);
  return { success: true };
} catch (error) {
  context.reportStatus('Error: ' + error);
  return { success: false };  
}

(This is just async function for handling one element from the stream, so you need a Promise.all in some top level to do the loop).

It's clear that the hotshots doing RxJS day in and day out can sling those concatMaps and mergeMaps in their sleep, but for an average developer - can you take a good glance at that RxJS and tell whether it's correct or not? Is the right operator being used? If you are speculating that a bug might be in that area of the code, how fast can you read and replay the flow in your head?

It is pretty clear that the wider web developer community already opted for Promises and async/await, how long does Angular community plan to go their own way?

(Before you ask, yes, I know Angular itself is built on RxJS - I have three pages of that in the call stack every time I hit a breakpoint).

Saving my stuff from Medium

Ville M. Vainio — Mon, 01 Jul 2019 20:04:01 +0000

As it appears, Medium is starting to use some Dark UX Patterns to paywall content. There have been several false alarms (accidental paywalling, "build my brand" hipsterism etc.) earlier, but it seems they are now all-in on their desperate monetization attempts.

Here's what I did to secure my stuff:

Exported the zip file of all posts from Medium Settings UI
Copied the "posts" folder from the zip (bunch of html files) to
my github repo
Converted them to markdown for easy reading on github with medium-2-md and npx:

$ npx medium-2-md convertLocal html/

This emitted a bunch of markdown files in a new directory. I deleted all the blog comments (nobody wants to read those!) and pushed the files to github, for easy reading. Here's an example blog post

All the gists (i.e. code snippets) are still missing from the markdown versions - so some scripting work remains to be done before pushing them elsewhere.

What didn't work

dev.to offers a way to import content from Medium through RSS feeds. In the spirit of dark patterns, Medium's RSS feed only has a few most recent articles (example here) so I abandoned that path.

Migrating to dev.to?

As it appears, dev.to is fast as heck. Pages practically load before you click them, so you manage to skim more posts per minute. I'll probably push all of these posts there once the preparation work is ready.

The first step though was to move everything to a public static hosting site (github). Now, Medium can go tits-up tomorrow for all I care!

Clean Code

Ville M. Vainio — Mon, 10 Dec 2018 17:28:24 +0000

Again, there is controversy around Robert C. Martin (known as “Uncle Bob” among his following), because of Trumpster sympathy accusations (which, even if they were proven, are not unusual for a man of his age).

At times like this, it’s good to study his earlier work, “Der saubere Code” (or “Clean Code”) to gain some perspective and make it evident that these accusations are without basis. It introduces a doctrine called SOLID, outlined below:

Single Responsibility Principle

Evolution of code must lie in hands of singular, animating principle, embodied by an anointed Leader.

Open/Closed Principle

Libraries should be Open for Use, but the decisions within the library must be Closed, stewarded by an educated board.

Liskov substitution principle (Liskovsches Substitutionsprinzip)

Manages relationships between Master- and subclasses. Subclasses, while independent, must always obey the rules set by Master Class, while retaining freedom to add their own functionality.

Interface segregation principle

“ To each their own” — different capabilities and freedoms fall naturally to different classes of users.

Dependency inversion principle

High level, policy-setting components should be independent of lower level components. Top tier is the unmovable, unquestioned layer that provides stability, while lower tiers go about their ways with little danger of disruption to the Whole.

As Spoken by a Dead Enterprise Developer by the Tree

Ville M. Vainio — Mon, 26 Nov 2018 20:21:02 +0000

Programmer said,

1. Like a good shepherd gently corrects the route of a wayward lamb, the shepherd of an application steers the code towards safer paths without coercing or blaming the code.

2. You have been told that you should use backslash in Windows as a path separator. But know that backslash is an abomination in my house and should only be used as an escape character. Let Windows software that breaks without backslash break, and let us not talk about that software anymore.

3. Man that thinks too much looks at an idea and thinks he can do better, and spends his nights belaboring for the perfect implementation without typing in the program. But his wise neighbor implements his first idea, sees how it operates and modifies it accordingly. His neighbor is blessed with riches and respect, while the man starves and is ridiculed.

4. You say you should depend on interfaces and not concretions. Yet you put the interface in the same dll as the implementation, like a drunkard that soils his pants also on the outside. Know that interface is of no use if it can not be used without dragging along the implementation.

5. If you inject your dependencies, you can have different life cycles and states within those dependencies. But transient dependency is almost like a static function when you look close enough.

Programmer said,

6. You were told to write many unit tests. Yet the man that told you, does not write unit tests in the privacy of his own house. Words are wind, and man is judged by his deeds, not his words.

7. Foolish young man sees a new library and knows that his elders don’t know it. So in order to acquire wives, the young man peacocks around with his knowledge above his elders, for surely he must be wiser than them. Instead, a wise man knows that the library was written by another such lovelorn young man, again to impress other people. Young man learns this from the wise man, studies computing outside JavaScript, and earns a respectable wife and a good house in his time.

8. Foolish old man wants to teach the youth in his village. But they won’t listen to him because he is old and busted. Do not be that old man. Instead, be the wise old man that listens to the youth, for they get around the block more and have their own stories of war and conquest to tell. And then see what you can use and what you must discard.

Programmer said,

9. You were said that Object Oriented is garbage and Functional Programming is too hard. But wise men know that Object Oriented programming is not garbage when done in moderation, and Functional Programming is not hard when done in moderation. And the village idiot, writing simple procedural programs in Go, laughs at both, with belly fat from rich foods and good life.

10. But yet know that Haskell is doomed to obscurity, as for obscurity it was written and in obscurity it thrives.

11. Text is bytes written as UTF-8. It shall not have a Byte Order Marker in the beginning, for that is an aBOMination. Let no more be said about that.

Programmer said,

12. Many men you respect use Rust and you aspire to the same. But you should not use Rust before they fix their editor support, for the editor support is still bad.

13. Wise man looks at code searching for expressiveness and clarity. But equally wise man accepts an ugly language if the tooling is built by rich masters with fanatic drive towards quality. Beautiful program will not keep you warm in winter breeze, but fast compiler just may.

Creating a Windows Forms GUI with F#

Ville M. Vainio — Sat, 14 Jul 2018 20:50:43 +0000

Windows Forms is not dead — it’s now more alive than it has been for years now that Microsoft announced they will support it in .NET Core 3.0, and that you will be able toembed “modern” UWP controls in Forms apps.

Besides not being dead, it has other things going for it:

It’s easy to use from F#, as you’ll see from this post. WPF requires more complex adaptation work (e.g. there is a XAML type provider), while Forms is pretty much straight .NET.
.NET Native (i.e. the “full” UWP stack) does not work with F# at all, and possibly never will — so it’s probably not going to be relevant to your choices.
Windows Forms uses the programming pattern familiar from Qt and other UI toolkits, so you can pretty much get going in a day.
It’s not a particularly good fit for “rich” or customized UI’s, but you are not writing those anyway. When you have someone paying you to do a rich UI for desktop, they are paying to do it on the Web.
It’s the real Native toolkit for Windows, so the applications can be very small. An application that does something can happen in 20kB (without F# of course, F# adds ca. 3MB of weight).
Windows Forms, unlike WPF or UWP, has a cross platform story and can be run in Mono under Linux/Mac.

With F# you say?

The problem with GUI programming with F# is that UI design tools are written for C# and VB programmers. The recommended approach has usually been to:

Create the GUI logic in C#, using the Forms UI Designer.
Use F# to make libraries and call out to them from the GUI.

The obvious problem with this is that you don’t really want to use C# more than necessary, and want to keep language context switching to the minimum — not to mention that you are limited to constructs that are well supported on C# side on the boundary.

Another approach, probably only appropriate for seasoned Forms developers, is to write everything in F# without using the Designer. This is outlined at least in the (excellent) “Expert F#” book, if you are curious how to do it.

The alternative approach I’m proposing here is to also write all the GUI logic in F#, only dropping to the C# side when you want to move things around in the Forms Designer. Your main entry point is the F# application, which then instantiates the main form (and subsequent forms). The forms register all their UI components with a “behind” class, which then binds the event handlers and implements all that hairy GUI logic in a language that is more aesthetically pleasing (that’s F#, if you are new here).

I’ll take a shortcut and use a Scaffer template to create the app skeleton:

Yikes! That was a lot of stuff. Fear, not, you only ever need to care about few of them. If you click through the files, you’ll notice that:

MathManDesign is a project (DLL) written in C#. That’s the one you’ll open in VS and click around the Designer.
MathManMain is the “main” application (“EXE”). It contains the entry point which bootstraps Windows Forms, instantiates the MathManForm and hooks up the “behind” class. It takes a project reference to MathManDesign project, but MathManDesign does not have any kind of reference to MathManMain. Therefore, you can go wild in using F# constructs that have usability issues when exposed to C# (e.g. DU’s). This dependency “inversion” is done by TrivialBehinds, a micro-DI-library available in nuget.

When you build and launch the application, you’ll see the minimal default functionality in action:

(to verify the behavior, I recommend clicking the button a few times and observing how the number after “Lorem ipsum“ in the label increments on each click).

It looks like this in the designer (double-click on MathManForm.cs to see the Design view):

And press f7 to get to the code:

After editing the form in the designer, you’ll add the new controls that it created in the MathManUi class. This is the only C# code you’ll need to keep up to date (of course it needs to be added for every Form you create). You can copy-paste the control declaration from MathManForm.Designer.cs.

Update: you can replace this boilerplate by CreateComponentBehind, if you want to expose the whole MathManForm instead of of MathManUi. In that case you need to make the controls public:

Now, let’s take a peek at the F# code running it all:

That’s it!

The first lines of main are standard Windows Forms bootstrap code. Then we instantiate the Form and start the application. The instantiation of the form instantiates the “behind” we registered in registerBehinds() function.

Doing it from scratch

Warning: stop reading if you are already bored.

I “cheated” a bit by using a template — because some boring work went into getting it working. For the posterity, here’s what was needed to get that F# application off the ground:

Create a solution
Create the F# application as “Console application” and reference Windows.Forms and System.Drawing from there.
Set the application type of the F# application to WinExe (otherwise you’ll get that empty terminal when running the application)
Create the Design project, in VS 2017 “new project wizard” it’s “Windows Forms Control Library (.NET Framework)”.
The .NET Framework to use should be .NET Framework 4.7.2, because font rendering will be fuzzy on Windows 10 on 4.6 series and older.
In order to fix font rendering, I had to modify App.config (check the link above), and create a manifest in the F# application. To do that, I just did “Add manifest” on the Design project and copied it over to F# application side.
Since you’ll have multiple projects, it’s good idea to migrate to Paket.
Add a nuget dependency to TrivialBehinds to both projects. You can probably get similar behavior with “actual” DI libraries (get class X that supports handling data package Y), but I couldn’t be bothered to add one of those heavy injectors here.

The skeleton code is at https://github.com/vivainio/FSharpFormsSkeleton — I’ll probably keep it up to date and modify the template if/when needs arise. If you are using that instead of Scaffer, you need to do some IDE legwork to rename those classes.

14 (fourteen) habits of Okay Programmers

Ville M. Vainio — Tue, 12 Jun 2018 19:03:29 +0000

Mastery is Grind

Setting the stage: you are a fresh mind entering the field. You don’t want to suffer from imposter syndrome or bear the dreaded mark of a “pleb”, but are confused on how to navigate the bewildering array of chaotic undercurrents in Real Programmer subculture. By practicing these simple steps you can ride that tiger all for all it’s worth.

Master the command line. You will be running lots of scripts and launch stuff from there, so why not get fluent at it?
Never have spaces in file or directory names, or anywhere else for that matter. If you get caught using one, you will be assumed to be “GUI-clicker” and beyond all repair. If your code is under a directory with a space in the name (or two in some extreme scenarios, I kid you not), it’s assumed to be garbage regardless of whether it was written by John Carmack himself.
Learn to think in types. If you are only doing dynamic programming languages at work, use a typed one at home. If you can’t think in types, your skills are assumed to be lacking regardless of your proven productivity or success in private life.
Learn a typed functional programming language (OCaml, F#, Scala, ReasonML, Haskell…). No matter how bad a programmer you really are, or however “unpopular” programming language (PHP, ES5, Java, …) you are forced to crank out at your day job , you are assumed to be on the top tier if you can comfortably sling one of these. Using Clojure or Elixir doesn’t count because1) these don’t have types and 2) they are perceived as “trend hopper” targets for the now-disbanded Ruby tribe. If you can be productive in Idris or other dependently typed language, you are assumed to be a Programming God despite never having closed a ticket you were supposed to work on. Extra caution : using Haskell may be perceived as “trying too hard”.
Only drink on Fridays. This ensures you have regained your mental acuity and creativity by Monday lunch time or Tuesday morning (depends on your age and stamina).
Solve as many problems as you can. If you don’t encounter interesting problems in your current tasks, help other people solve their problems or create side projects where you can practice solving new interesting problems.
Code as much as you feel like. 8 hour workday can only fit certain amount of coding, and you can certainly be “good enough” for your employer if you stick to that. But if you code more, you will be better. Programming is practice, practice, practice. People will routinely tell you otherwise, but parents also tend to compliment the singing of their children.
If you have to draw pictures to understand something, draw them on pencil-and-paper. Git is where your work output should go. Like the sound of tree falling in the forest without anyone listening, work that didn’t end up in Git will be perceived as work that didn’t happen. Exception : if you helped someone land something in Git, you can rationalize having sort of kind of done useful work (maybe).
If you are male, try growing a beard if you can. You don’t have to wear it at all times, but at least ensure there is a verified scenario where you, in fact, were seen as having sufficient amounts of beard. If you are a woman, moderation is advised regardless of whether you can grow one or not.
Do not use shell scripting languages (bash or .bat/.cmd files, or Powerhell) if you have more than 2 lines of “code”. Use Python (or Ruby if you must) instead. If someone doesn’t have Python installed, he’s not worthy of running your scripted masterpiece anyway.
Have hobbies outside programming. At least read a book or play some video games sometimes for chrissake.
Acquire a good arsenal of so called “thought leaders” you follow in Twitter. They should mostly consist of battle-hardened veterans aged 35 or above. The younger ones will lead you down the swamp of Node and other subcultures that are not perceived to be sufficiently programmer-y. On the other hand be wary of exceedingly old thought leaders that are perceived to be out of style (like “Uncle Bob”, or SOLID patterns in general).
Follow programming news. On Reddit, /r/programming and /r/programmingcirclejerk provide affordable value at good regularity. HackerNews (also known as the “orange website” because the maintainers can’t do CSS) has a small cult following, but 1) you can’t get “just programming news” from there and 2) the community (a.k.a “webshits”) overall is annoying and verbose, and reading too much of their output can lead to reduction of social skills, such as they are.
“It’s nice to be important but it’s more important to be nice” , to paraphrase a German philosopher. If you are an Okay Programmer but arrogant or mean, you will be like that clunky old cog in a machine that just gets to stay there because yanking it out would require disassembling too much other stuff.

Your mileage may vary, and this blog post should not be treated as Gospel. For one, it was written by single author (as opposed to Gospels, of which there are four at the time of writing this).

MobX with Angular, Part 2: Patterns, Perks and Gotchas

Ville M. Vainio — Mon, 30 Apr 2018 20:07:13 +0000

State management shouldn’t be rocket science

This is the second installation of the critically acclaimed “MobX with Angular” series. If you came here googling for “ngrx alternatives sweet jesus make it stop”, you are in the right place. You probably want to read part 1 for the basics (or any generic React-oriented MobX tutorial if you don’t particularly like my writing).

On to the non-basics. We are creating a big Angular application with a largish, geographically distributed team at Basware, and have established this as a pretty workable design (for the purposes of discussion I’m using the classical Blog Post feature as the example):

The single source of truth is the Store, posts.store.ts (class PostsStore). It contains the @observable properties, and all the @action’s that modify the state.
There are many Stores. You could have AuthorsStore, SettingsStore etc.
Components don’t access (i.e. inject) the Store directly. Instead, they use a facade called PostsService, in posts.service.ts.
Http requests are done by PostsApiService, in posts.api.ts. This is the only place that knows what url’s are used. This is also a good place to put a breakpoint when wondering why on earth that one request was sent three times.

The Facade

PostsService is responsible for exposing parts of the Store to the components. That is, it’s what your post-reader.component.ts injects to do stuff.

If there is asynchronous http work to do, PostsService calls to posts.api.ts service (PostsApiService) that sends the request. PostsService then captures the response and updates the state accordingly (usually calling an action in Store). Here’s an example flow:

User clicks a post. Component calls postsService.documentChanged(id) which is a hint that we want the data for that document.
PostService notices that we don’t have that document in store. It triggers the fetch knowing it’s needed soon.
PostsReaderComponent is observing postService.getPost(id). It keeps returning undefined (or null if you are so inclined) for now. A busy spinner is spinning.
PostService finally receives the post content. It calls the action store.setPost(id, { content: “blah blah”})
The observer of getPost(id) is woken up now that the data changed, and it can place the content in a component instance variable. This dismisses the spinner and reveals the glorious post content.

It’s worth mentioning that MobX itself has support for async workflows, through async actions and flow(). We are not using those because

we want to stick with relatively tried-and-true async patterns familiar from AngularJS 1.x days
generators don’t work great (read: hardly at all) with current crop of debuggers and source maps
async is not exactly rocket science. Every action on the store is a dumb, instant “commit”.

createTransformer()

You noticed the postService.getPost(id) above. It will probably look for the content in an observable Map. You can call it in autorun body just fine, but there is actually a better and faster way.

Usually, MobX recommends doing most calculations in @computed properties instead of complex autorun bodies when you can:

It’s faster. When a computed property is observed, it is “hot”. That is, when the data or other computed properties are modified, the computed values are pushed out and memoized. Just calling the computed property will get you the memoized value. If there are many components observing the same data in autoruns, they will be recalculated every time the data changes. With computed properties, the calculation is run only once. This means you can safely call them without worrying about performance under the hood.
They are a cleaner programming pattern. When you see something is computed, you know it’s just a pure projection of underlying state. And, you know you should be observing that state in the top level autorun() somewhere. Non-computed things could be doing anything else. You’ll probably implement your state by having a whole tree of projections refining and improving the state to fit your particular consumption needs.

Now that I convinced you of their merits, here comes the Gotcha 1: you can’t pass arguments to computed functions. They are just getters with no arguments. You could just have “currentPostId” in store, and give data for that current post in the computed getters. But, this won’t work if you have multiple posts being observed at the same time (say, you have a two pane post reader showing different posts at the same time).

This is where createTransformer() in mobx-utilssteps in (if you understood none of the official description, read on). Here we create a getPostAndAuthorData (in PostsService class body) that reads stuff from two different transformers (projections):

The call to getPostAndAuthorData() discovers the internal computation by looking it up by the postId. You can only pass one primitive argument to the transformation, but I know that you, Dear Reader, will usually be using a string documentId or somesuch. If you would need something more complex, eat it up and use autorun() instead.

Component code

In the end, you’ve got to be observing the data in autorun, otherwise it’ll all be for naught. For our application, we have made a utility to

Create a list of autoruns.
Dispose them in ngOnDestroy().

It’s used like this:

The strings in there are names of the observables, so mobx-devtools Chrome plugin (that also works with Angular) shows them nicely. You can grab the utilities (startObservers, addComponentDisposer and stopObserving) from Github. The first argument to startObservers() is optional; if you pass the component ChangeDetectorRef there, triggering any of the listed observers will also run change detection on that component. This is usually needed for OnPush components.

Why not shove everything in one autorun? The basic idea is to segregate them so that only the part that depends on a particular change is run when needed.

Natural place to “start observing” is ngOnInit(), since that is only run once per component, and the components input attributes have settled by the time it runs. You can delay the initialization of observables by MobX when() function that retuns a promise that resolves when the observed expression returns true:

There is no such thing as free lunch

With all this magic and rainbows, there’s got to be a price to pay, right? Well, there is, and sooner you know the better:

Decorators like @observable and @computed can’t currently (as of Angular 5) be used in components because AoT compiler chokes up on them. createTransformer(), on the other hand, can be used, and can be handy for some marginal refinement you want to do at the edges. MobX 4 provides an alternative syntax using declare(), which won’t trigger this problem.
The observable data in stores is injected with MobX specific metadata, and the attributes of objects are transformed to getters/setters. This means you need to click individual properties in the debugger to investigate them.
Observable arrays look bad in the debugger. You will see hundreds of items per array, and need to click through the items to even see the length. Upcoming MobX 5 will fix this (by using ES6 proxies).
Some JavaScript libraries can when fail dealing with observable data structures. E.g. lodash _.flatMap (which is lodash version of smooshMap()) just fails to deliver with an observable array. To be fair, that’s the only bad lodash function that I know of, so no need to throw out lodash quite yet.

The last three problems above can be avoided by using toJS() in your computeds/transformers/autoruns — so you won’t see the guts of observable data structures at the edges. You can also log stuff to console through toJS():

All that being said, the debugger experience with MobX is very good. If you set a breakpoint in autorun or computed property, you see precisely what triggered the change from the call stack — and the call stack fits on the screen, as opposed to anything involving RxJS observables.

Should you still be using RxJS?

A good rule of thumb is: not as much as you did.

For dumb components that don’t want to take dependency to any kind of store, pass immutable objects as inputs, and reassign the value to trigger component update (for OnPush components).
Sometimes you have scenarios where component needs notification for events (as opposed to changing state as pure function of data in store — something you should do most of the time). Creating a BehaviorSubject in a service provided at component level is fine for that. The alternative of passing @Output events through every level can get cumbersome. Real life example: we are broadcasting events from ag-grid through a BehaviorSubject for the components above.
Methods in your http api services (e.g. PostsApiService) usually start the HttpClient observable and map() it a bit to mungle the data. If the logic gets complex enough to not be readily readable using RxJS (e.g. once you go beyond trivial map()), you shouldn’t be shy to run .toPromise() on the observable and use async/await. Your pull request reviewers will thank you for it.

MobX with Angular: the Prelude

Ville M. Vainio — Sun, 14 Jan 2018 19:37:26 +0000

Conan experimenting with NGRX

This is Part 1 of the in-progress article series. Part 2 with more advanced concepts is also available.

I hit a degree of analysis paralysis on writing an “all in one” blog post about using MobX on Angular (2+) at Basware, but it ended up being a bit heavy reading. Instead of that I’m doing a series of shorter, hopefully harder-hitting posts. (Narrator: this one ended up being neither short, nor hard-hitting)

Aim is not to teach you MobX, but rather to generate some appetite for the productivity wins you can reach with it — and maybe help you debug some of your personal misconceptions faster (I also had some in the beginning).

The Store

MobX is not really built around “Stores”. You can have your state spread over however widely you want (e.g. dozens of different Angular services or ES6 classes if you are so inclined). Simple state is always easier to track, but there is no need to cargo cult a single God-object to hold everything. The mechanics of MobX will work regardless of how you split your state.

Observables

There is probably a small subset of state that actually needs to change. These are marked by @observable decorator, and they are usually primitives, arrays, objects and ES6 Maps. Note that, for better or worse, you must use ES6 Maps instead of objects to represent dictionaries (as MobX can’t detect keys being added to objects). “Changing the state” means writing to these fields (mutating, reassigning, whatever).

Computed properties

@computed decorator marks an ES6 property getter that uses some of the observables defined above to calculate derivable parts of the state. If you have observable’s called “foo”, “bar” and “baz”, you can use computed properties to produce e.g. { foo, bar } object if both are defined, or null otherwise. You need that new unique object to trigger OnPush change detection, among other things. If “baz” property changed, your computed property comfortably sits as the old value, without unwanted triggers of OnPush change detection.

Autorun

This is where the actual magic happens.

Autorun is a function that:

You probably have in your ngOnInit(). Class constructor is too early (e.g. Angular ChangeDetectorRef is not available there).
Is run once in the beginning. MobX records what properties (observable’s and computed’s) from MobX stores it accesses, and remembers its dependencies.
Is run again when any of your dependencies change.
Remains “hot” until you unsubscribe from it. autorun() returns a callable disposer that you will call in your ngOnDestroy for the component.

What’s in your autorun() in a typical Angular application? You can have code that:

Copies values from store to your local component variables that are used from the template.
Runs patchValue() on a Reactive Form within the component.
Does some last minute tuneups for the data to make it easier to access from the template.
Calls ChangeDetectorRef.detectChanges() to force Angular to check changes in case you are within a ChangeDetectionStrategy.OnPush component (and didn’t trigger any Input to change).

A single component can have many autorun() blocks. The smaller and more granular the blocks, the more specific you can be about how often they fire.

Autoruns are not limited to components though! Services can have their own autorun’s observing the state, possibly initiating HTTP requests when interesting data is available in stores, and commit interesting responses back to the stores when they return.

Don’t you need a new library for this?

Not really. Core MobX works fine with Angular, with the scheme mentioned above.

We have a few convenience functions to help with disposing autoruns, like this:

You call startObserving(this, () => …) in ngOnInit(), and stopObserving(this) in ngOnDestroy. There will be a new blog post with some more productized helpers later on.

There is also https://github.com/mobxjs/mobx-angular project that detaches a component completely from normal Angular change detection. It can work for your needs, but I posit that you may not need it, and operating directly with the (already simple) core MobX API can help when debugging problems in your own logic (e.g. “why did this not change? I better set a breakpoint in my autorun!”)

How about Rx Observables?

We started out by piping stuff from MobX as Rx observables to our components, as described here: https://netbasal.com/managing-state-in-angular-with-mobx-51191803e14f

Still, I was left wondering “y tho”. If you are just using autorun(), you avoid that unnecessary wrapper, and remove need to use async pipes. You just assign new immutable references (that you got from @computed getters or autoruns) to your component variables and their change detectors kick in.

MobX itself, despite its simplicity and ease of use, is a sophisticated reactive system on its own right. It just gives you the same power you get with Rx with a cheaper price tag (no need to do combineLatest(), switchMap() etc. to express a fundamentally simple computation).

How about NGRX?

Bright eyed and bushy tailed, we started out with NGRX; it has a very good industry buy-in, is based on React community darling Redux, and is being pushed by a cadre of Angular community hotshots. So it’s going to be the default conservative choice, right? Right?

It was a traumatizing experience for me personally. There was one directory with 5 files to represent something that was 5 lines with MobX — basically an array.

I wanted to give it a week to sink in, but I think I managed 2 days of zero productivity before calling off the experiment. Now, I have done some horrible things in my past (Symbian C++, raw GObject macro programming, 4GL’s, Perl…), but it’s 2018, I’m not getting any younger, and frontend development should be a bit fun and playful — experimenting with different state schemas and so on should be natural, energizing part of the work.

Call to action

So a degree of “Question authority” is in order here. If we see MobX as the better mousetrap for Angular, we should drive that point more consistently. We should start writing developer tools that illustrate the data flow on the screen. Barring everything else, we can at least make some noise in the blogs.