DEV Community: Aviad Pineles

C# - Enums and Bug Resilience

Aviad Pineles — Mon, 27 Sep 2021 13:20:30 +0000

Our domain is made of sets. Some sets are trivial such as all integers (int) or all booleans (bool) but often we are dealing with sets that are more narrow, for example the possible states of an order (Incomplete, Unpaid, Paid, Shipped, etc.).

In our database we assign a number or a string that represents each possible value, and in our code we use an Enum for that. This is good, but if we are not careful, then at some point in the future, when we change the composition of the set (for example by adding another state Received), we might create hard to debug errors in our program.

We want to always use switch when dealing with these sets, so that when the set changes, the compiler automatically warns us about all the places where code might need to be changed.

However there's one case where this is tricky: when dealing with the database. For example, we have a query in our code that fetches all orders that are paid, so our LINQ condition could be something like this:

where order.status == OrderStatus.Paid ||
      order.status == OrderStatus.Shipped

But what happens when we now add the new Received state? This query is now broken because received orders are also paid, but the compiler doesn't have any way of knowing that!

We need to somehow add a switch to this operation to make it safe. What we must do is filter all the elements of the enum by our condition:

IEnumerable<OrderStatus> GetOrderStatusValuesWhichArePaid() {
    static bool IsPaid(OrderStatus orderStatus) => orderStatus switch {
        OrderkStatus.Incomplete => false,
        OrderkStatus.Unpaid => false,
        OrderkStatus.Paid => true,
        OrderkStatus.Shipped => true,
        _ => throw new ArgumentOutOfRangeException(nameof(orderStatus))
    };

    return Enum.GetValues<OrderStatus>().Where(IsPaid);
}

And we can use it in our LINQ query:

var paidStatusValues = GetOrderStatusValuesWhichArePaid();
var query = from order in Orders
            where paidStatusValues.Contains(order.status)
            select order;

Now when we add the new Received state, the compiler can warn us that the switch statement in the function IsPaid is not covering all cases properly.

Angular - Wait for All Images to Load

Aviad Pineles — Sun, 15 Aug 2021 12:49:42 +0000

I was recently engaged in a long discussion on StackOverflow with some programmer who was having a problem. They wanted to run some process which was sensitive to the particular sizes and locations of the images on the page, so they had to find a way to wait for all the images to be done loading, before proceeding.

The naïve solution that was considered, was to subscribe to the window.load event, which fires when all images are loaded on initial page load. This would work only for the initial load of the Angular page, but thereafter, navigating within the app would not cause a page reload and there would be no obvious way to detect when new images were being added to the page.

The actual solution I came up with involved creating an Angular directive and a service. The directive attaches to all <img> tags, and subscribes to their load and error events, and the service coordinates and keeps track of all the events, and maintains a running list of images that are still being loaded.

Here's the directive:

@Directive({
  selector: 'img'
})
export class MyImgDirective {

  constructor(private el: ElementRef,
              private imageService: ImageService) {

    imageService.imageLoading(el.nativeElement);
  }

  @HostListener('load')
  onLoad() {
    this.imageService.imageLoadedOrError(this.el.nativeElement);
  }

  @HostListener('error')
  onError() {
    this.imageService.imageLoadedOrError(this.el.nativeElement);
  }
}

Here's the service:

@Injectable({
  providedIn: 'root'
})
export class ImageService {
  private _imagesLoading = new Subject<number>();
  private images: Map<HTMLElement, boolean> = new Map();
  private imagesLoading = 0;

  imagesLoading$ = this._imagesLoading.asObservable();

  imageLoading(img: HTMLElement) {
    if (!this.images.has(img) || this.images.get(img)) {
      this.images.set(img, false);
      this.imagesLoading++;
      this._imagesLoading.next(this.imagesLoading);
    }
  }

  imageLoadedOrError(img: HTMLElement) {
    if (this.images.has(img) && !this.images.get(img)) {
      this.images.set(img, true);
      this.imagesLoading--;
      this._imagesLoading.next(this.imagesLoading);
    }
  }
}

A brief recap of the mechanism, a directive attaches to all <img> tags, and registers them with the service, while listening to the load and error events. The service increments a counter every time a new image is registered with it, and decrements the counter whenever the directive tells it that the image has finished loading (or reached an error state, in case of a broken image link). Every time the counter changes, the service emits the number of loading images, and the consuming component subscribes to that observable and knows that all images have finished loading when it sees a value of 0.

Rxjs Expand - Reactively Retrieve All Rows From a Paginated Source

Aviad Pineles — Sun, 15 Aug 2021 09:22:15 +0000

Let's say you have a data source which is paginated, so you can request this page or that, but you can't request all the entries at once. Now, regardless of whether it is right or not, how would you approach this task, if you wanted to do it anyway?

One approach would be imperative. In the imperative way, we use a loop, get one page, wait for the results, get the next one, and so on. When a page query returns no results, we return the collected results.

let pageNumber = 0;
let results = [];

do {
  const pageResults = await getPage(pageNumber++).toPromise();
  results = results.concat(pageResults);
} while(pageResults.length !== 0);

return results;

But imperative is so 2nd millennium, we want to do some reactive magic! Enter expand...

The expand Rxjs operator takes an input, and returns an observable. It then emits from that observable, but for each emitted item, it calls itself recursively. In our case the recursion is simple, call with page: n+1 until no more data arrives.

For this recursion to be valid, expand needs to return an observable of the same type of its input, and this input must contain the page number, so we must "annotate" our results with the page number as well.

const getPageAnnotated = pageNumber =>
  getPage(pageNumber)
    // Annotate with the page number
    .pipe(map(results => ({ results, page: pageNumber })));

return getPageAnnotated(0).pipe(
  expand(pr => getPageAnnotated(pr.page + 1)),
  takeWhile(pr => pr.results.length !== 0),
  map(pr => pr.results),
  scan((acc, v) => [...acc, ...v])
);

Although this works, the astute will notice that we're missing the termination condition in the expand call. So how come it works without it? The answer is takeUntil - because we are completing the entire stream as soon as a query returns with no results, the next query will get cancelled.

This might be harmless, but we can avoid it easily by changing the expand call to:

expand(pr => pr.results.length !== 0 
               ? getPageAnnotated(pr.page + 1) 
               : EMPTY)

This way we will not try to get the next page, if the result from the current page is empty.